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Abstract 



The SPKI/SDSI is a security infrastructure whose principal goal is to facilitate the building of secure, 
scalable, distributed computing systems. In SPKI/SDSI the principals are the public keys and each 
public key is a certificate authority. Given a set of SPKI/SDSI certificate, the decision on granting 
access to a resource by a user is taken by using a certificate-chain discovery process. A certificate- 
chain for a set of certificates C is of the form C& o c^-i o ■ ■ ■ o c\, where c\, c-i, . . . , C& are certificates 
in C. Given the set of certificates C, the public-key of resource owner K r , client requesting access 
to the resource K c , and access right T requested, a certificate-chain discovery algorithm looks for a 
finite set of certificate chains proving that K c is allowed access specified by T on the resource K r . As 
per RFC2693 SPKI/SDSI infrastructure allows validity specification. The validity specification is a 
time period during which a certificate is valid, assuming the signature verifies. The certificate expired 
beyond the validity period specified against the certificate. The validity specification takes the form 
(ti, ti), specifying that the certificate is valid from time t\ to time t-i, both inclusive. This validity 
specification, as defined in the RFC-2693, allows for a limited constraints on the certificate. The RFC- 
2693 also allows for more powerful constraints specification that can be associated to the certificates of 
the SPKI/SDSI system. In this report it is demonstrated how Weak monadic Second-order theory of 
1 Successor (WS1S) can be used for specification of more generic validity constraints. It is also shown 
that the WS1S logic can be combined with Weighted Pushdown System (WPDS) to formally specify 
more generic constraints and answer authorization questions that are based on the constraints. This 
is accomplished by augmenting the WPDS, called AWPDS, so that the rules of WPDS are associated 
with WS1S formula and the transitions of the prefix closed configuration automaton generated from 
WPDS is annotated with regular language, which is succinctly represented by an automaton. The 
concepts described has been implemented as a tool called SCAT and the feasibility of using WS1S for 
the description of complex constraints has been demonstrated by implementing a parser-complier named 
FACT, which uses a physical access control domain specific language and outputs WS1S formula. 
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Notation and Abbreviations 



Terms 

Subject - The entity of an access control system that accesses resources like files, direc- 
tories. 

Object - The resource in a system that is protected by the access control system. 
Access Control - The means of controlling access to an object by a subject. 
Policy - A statement of what is, and what is not, allowed in an access control system. 
Authentication - A method of verifying the identity of a user or an entity in an access 
control system. 

Authorization - The process of determining what access rights are provided to the sub- 
ject over an object. 

Access Control List - A list that specifies what access privileges subjects have over an 
object. 

Issuer - The public-key that signs the certificate. 

Validity Specification - A time period during which a certificate is valid, assuming the 
signature verifies. Beyond this period, the certificate has expired, and should be renewed. 
Identifier - A word over some alphabet used in SPKI/SDSI system. 
Tag - The specific authorization or authorizations being granted from the issuer to the 
subject. 

Delegation Bit - A boolean value which if set to true for a certificate specifies that the 
subject of this certificate is able to grant to other principals any subset of the autho- 
rization that it is receiving from the issuer of this certificate. If it is set to false for 
the certificate it specifies that the issuer is not delegating to the subject the authority 
granted to it. 



Certificate - A digital signature to bind together a public key with an identity informa- 
tion such as the name of a person or an organization, their address, and so forth. The 
certificate can be used to verify that a public key belongs to an individual. 
Threshold Subjects - The minimum number of subjects from a given set of subjects who 
must agree to sign the request before authorization can be propagated through the cer- 
tificate. 

Lattice - A partially ordered set (or poset), in which all nonempty finite subsets have 
both a supremum (join) and an infimum (meet). 

Principal - An entity in access control system that can be positively identified and ver- 
ified using authentication techniques. 

Confidentiality - The process of concealment of information or resources. 
Integrity - The trustworthiness of data or resources. It is usually phrased in terms of 
preventing improper or unauthorized change. 

Availability - The ability to use the information or resource desired at the moment of 
request. 

Threat - A potential violation of security. 

Attack - The actions that causes security threats to be realized. 
Disclosure - An unauthorized access to information. 
Deception - An act resulting in an acceptance of false data. 
Disruption - An interruption or prevention of correct operation. 
Usurpation - An unauthorized control of some part of a system. 

Detection - The mechanisms that aids in reporting that the data's integrity is no longer 
trustworthy. 

Secure System - A system that starts in an authorized state and cannot enter an unau- 
thorized state. 

Breach Of Security - The act of the system being in an unauthorized state. 
Integrity Policy - The parts of the security policy that describes the conditions and 
manner in which data can be altered. 

Security Model - An abstract model of security used to understand the security system. 
Discretionary Access Control - An access control mechanism in which an individual user 



can set an access control mechanism to allow or deny access to an object. 
Mandatory Access Control - An access control mechanism in which the system controls 
access to an object and an individual user cannot alter that access. 
Originator Controlled Access Control - An access control system that bases access deci- 
sion on the creator of an object or the information it contains. 

Granting (Authorization) - The act of providing access permission that was provided to 
a subject over an object or set of objects. 

Revoking (Authorization) - The act of removing access permission that was provided to 
a subject over an object or set of objects. 

User - The subjects in the access control system who access the objects. 
Client - The computer system or the user which is the subject that access the object in 
access control system. 

Context Based Access Control - An access control system that is characterized by a 
context that defines the state of a system at a given time. 
Group - A set of principals in SPKI/SDSI. 

Certificate Chain - A base certificate plus a sequence of all certificates which establishes 
connection between the certificates. 

Authorization Flow - The flow of authorization from one principal to another using del- 
egation in SPKI/SDSI. 

Symbols 

K, - The set of public keys in SPKI/SDSI. 

K, K A , K B , K' - The specific keys in SPKI/SDSI. 

£ - The alphabet from which the set of words is formed which form the subset of an 

identifier in SPKI/SDSI system. 

A - The set of identifiers in SPKI/SDSI. 

Term - A key follow by or more identifiers. Terms are either keys, local names, or 

extended names. 

Local Name - The name in SPKI/SDSI which is of the form K A, where K G K. and 

A G A is an identifier. 



Extended Name - The name in SPKI/SDSI of the form K a, where K G K. and a is a 

sequence of identifiers of length greater than one. 

T - The set of terms in SPKI/SDSI certificate system. 

C - A hnite set of SPKI/SDSI certificates. 

K-c - Keys that appear in C. 

lc - Identifiers that appear in C. 

W - Weighted Pushdown System. 

A - Augmented Weighted Pushdown System. 

Acronyms 

ACF - Access Control Function. 
ACM - Access Control Matrix. 

AWPDS - Augmented Weighted Pushdown System. 
MAC - Mandatory Access Control. 
DAC - Discretionary Access Control. 
ACL - Access Control List. 

SPKI/SDSI - Simple Public Key Infrastructure and Simple Distributed Security Infras- 
tructure. 

WPDS - Weighted Pushdown System. 
PDS - Pushdown System. 
GPP - Generalized Pushdown Predecessor. 
GPR - Generalized Pushdown Reachability. 
GPS - Generalized Pushdown Successor. 
FSM - Finite State Machine. 
CRL - Certificate Revocation List. 
PKI - Public Key Infrastructure. 
IBAC - Identity Based Access Control. 
RBAC - Role Based Access Control. 
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Introduction 



1.1 Access Control - An Overview 

Security of a resource (physical or logical) rests on three fundamental security services which are - 
confidentiality, integrity, and availability. The interpretations of these three aspects vary, as do the 
contexts in which they arise. One way to ensure security of a resource is to provide managed access to 
the resource based on a set of permissions or policies that are defined for the resource and the agent 
accessing the resource. The means of managing access to resource is called Access Control. An access 
control system consists of policies, which protect resources, which is generically referred to as Object by 
agents that are interested in accessing the resources, which is referred to as Subject. 

Confidentiality is concerned with the concealment of information or resources. Access control mech- 
anisms support confidentiality by guarding access to resources based on Policy Specification and its 
enforcement. A policy specification unambiguously specifies the type of access that a set of Subjects 
have over a set of Objects. 

Integrity refers to the trustworthiness of data or resources, and it is usually phrased in terms of 
preventing improper or unauthorized change. Integrity includes data integrity and origin integrity. In- 
tegrity mechanisms fall into two classes: prevention mechanisms and detection mechanisms. Prevention 
mechanisms seek to maintain the integrity of the data by blocking any unauthorized attempts to change 
the data or any attempts to change the data in unauthorized ways. The former occurs when a user 
authorized to make certain changes in the data tries to change the data in other ways. Detection 
mechanisms do not try to prevent violations of integrity; they simply report that the data's integrity 
is no longer trustworthy. Detection mechanism may analyze system events to detect problems or may 
analyze the data itself to see if required or expected constraints still hold. Working with integrity is 
very different from working with confidentiality. With confidentiality, the data is either compromised 
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or it is not, but integrity includes both the correctness and the trustworthiness of the data. Integrity 
in a system that changes with the context is a challenge. A security system that that evolves with the 
changing context is required. 

Availability refers to the ability to use the information or resource desired. Availability is an impor- 
tant aspect of reliability as well as of system design because an unavailable system is at least as bad as 
no system at all. A major factor influencing availability is the ability of the system to tolerate faults. 
The factor of availability can be built into a access control system during the policy specification stage. 
This also means that degree of availability of a system can be measured given the specification of access 
control. 

Threat is a potential violation of security. The violation need not actually occur for there to be a 
threat. The fact that the violation might occur means that those actions that could cause it to occur 
must be guarded against. Those actions are called Attacks. The three security services - confidentiality, 
integrity, and availability - counter threats to the security systems. Threats can be divided into four 
broad classes: disclosure, or unauthorized access to information; deception, or acceptance of false data; 
disruption, or interruption or prevention of correct operation; and usurpation, or unauthorized control 
of some part of a system. Analysis of security system is an important method to ensure that threats 
are avoided and services are unhindered. 

In any access control system there exists a crucial difference between the policy and the mechanism. 

Definition 1. A Security Policy is a statement of what is, and what is not, allowed. 

Definition 2. A Security Mechanism is a method, tool, or procedure for enforcing a security policy. 

Policies may be presented mathematically, as a list of allowed (secure) and disallowed (non-secure) 
states. Given a security policy's specification of "secure" and "non-secure" actions the security mecha- 
nisms can prevent the attack, detect the attack, or recover from the attack. The strategies may be used 
together or separately. Prevention means that an attack will fail. Detection is most useful when an 
attack cannot be prevented, but it can also indicate the effectiveness of preventive measures. Recovery 
attempts to stop an attack and later to assess and repair any damage caused by that attack. 

The design of a system translates the specifications into components that ensures that system is 
correctly partitioned into secure and non-secure states. Given a design, the implementation creates a 
system that satisfies the design. If the design also satisfies the specification, then by transitivity the 
implementation will also satisfy the specifications. The cycle of identification of threat followed by 
design and operation of security mechanism is shown in Figure 1.1. 

1.1.1 Security Policies 

The Definition 1 is formalized here by using the concepts of secure and non-secure states introduced in 
the previous section. This definition provides an alternative view of the security policies. 
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Figure 1.1: Security Cycle 

Definition 3. A Security Policy is a statement that partitions the states of the system into a set of 
authorized, or secure, states and a set of unauthorized, or non-secure, states. 

The definition of three basic security services are formalized below in the context of the formal 
definitions provided in this section. A security policy sets the context in which a secure system can be 
defined. It may be noted that what is considered secure under one policy may not be secure under a 
different policy. 

Definition 4. A Secure System is a system that starts in an authorized state and cannot enter an 
unauthorized state. 




Figure 1.2: A finite-state machine for a secure system in which the authorized states are s\ and S2- 



A security policy considers all relevant aspects of confidentiality, integrity, and availability. With 
respect to confidentiality, it identifies those states in which information leaks to those not authorized 
to receive it. This includes not only leakage of rights but also the illicit transmission of information 
without leakage of rights, called information flow. Also, the policy must handle dynamic changes of 
authorization, so it includes a temporal element. This aspect of policy is called confidentiality policy. 
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With respect to integrity, a security policy identifies authorized ways in which information may be 
altered and entities authorized to alter it. Authorization may derive from a variety of relationships, and 
external influences may constrain it. Those parts of the security policy that describes the conditions 
and manner in which data can be altered are called the integrity policy. With respect to availability, a 
security policy describes what services must be provided. 

Definition 5. A security model is a model that represents a particular policy or set of policies. 

A model abstracts details relevant for analysis. Analysis rarely discuss particular policies; and focus 
on specific characteristics of policies, because many policies exhibit these characteristics; and the more 
policies exhibit those characteristics, the more useful the analysis. 

A security policy may use two types of access controls, alone or in combination. In one, access 
control is left to the discretion of the owner. In the other, the system controls access, and the owner 
cannot override the controls. 

Definition 6. If an individual user can set an access control mechanism to allow or deny access to 
an object, that mechanism is a discretionary access control (DAC), also called an identity-based access 
control (IB AC). 

Discretionary access controls base access rights on the identity of the subject and the identity of the 
object involved. Identity is the key; the owner of the object constrains who can access it by allowing 
only particular subjects to have access. The owner states the constraint in terms of the identity of the 
subject or the owner of the subject. 

Definition 7. When a system mechanism controls access to an object and an individual user cannot 
alter that access, the control is a mandatory access control (MAC), occasionally called a rule-based 
access control. 

The system enforces mandatory access controls. Neither the subject nor the owner of the object can 
determine whether access is granted. Typically, the system mechanism checks information associated 
with both the subject and the object to determine whether the subject should access the object. Rules 
describe the conditions under which access is allowed. 

Definition 8. An originator controlled access control (ORCON or ORGCON) bases access on the 
creator of an object or the information it contains. 

1.2 Motivation and Problem Formulation 

Security in a distributed system is a challenging proposition, especially the authorization function of 
the distributed system's security. The problem of authorization can be divided into two related sub- 
problems - representation and evaluation. Representation refers to the specification of authorization 



Chapter 1. Introduction 



requirements, while evaluation refers to the actual determination of the authorities of the subjects given 
the authorization requirements. The authority of a subject is its rights to access objects [1]. The 
focus of the work described in this thesis is the evaluation of the constraints to check if authorization is 
granted given the constraints in the context of SPKI/SDSI certificate system in which constraints can 
be a generic set of constraints represented using logic based formalisms. 

Simple Public Key Infrastructure and Simple Distributed Security Infrastructure (SPKI/SDSI) [2] 
provides a natural framework for authorization in distributed systems. SPKI/SDSI allows distributed 
security policy definition using public keys and decentralized name space. It is also an elegant practical 
system that addresses the problem of ensuring that a user is authorized to perform an action, not just 
the problem of identifying the user. In SPKI/SDSI system the certificates are used to ensure confiden- 
tiality, integrity and availability. It does incorporate a notion of authentication as well where the linked 
local namespaces bind keys to names. This notion of authentication is more general than conventional 
hierarchical PKI naming. The set of certificates that are defined by the security administrator dur- 
ing security cycle of the system being protected partitions the system into the secure and non-secure 
states described above. The use of certificates during the authorization process ensures that the system 
is always in 'safe' state. SPKI/SDSI authorization system can be employed in both DAC and MAC 
scenarios and provide flexible and decentralized authorization infrastructure. 

The SPKI/SDSI system as defined in RFC-2693 [2] allows for inclusion of validity period for each 
certificate. The validity period defines a date pair - not-before and not-after - within which the certificate 
is valid. For example, the validity period might specify a validity period as [05/06/2007, 12:00 AM - 
10/07/2007, 4:00 PM] which defines the time period in which the validity of the certificate is guaranteed. 
The definition of validity provides a check on malicious or inadvertent mis-use of the certificate. In 
addition to time based validity constraints, the SPKI group has also identified that "on-line tests of 
various kinds" are also validity conditions. These validity conditions further refine the valid date range 
of a certificate. Three kinds of on-line tests are envisioned: Certificate Revocation List (CRL), Re- 
validation and One-time. 

The RFC-2693 also provides for additional flexibility for performing on-line validity checks on the 
certificates. Though the RFC provides some pointers to validity condition models to use, it leaves room 
for inclusion of other models. This provides an opportunity to include additional validation models that 
caters to new requirements driven by different application and business scenarios. As described by Lee 
et al. in [3] it may be required to grant authorization decisions based on information of entities that 
describe their attributes, environmental conditions, and other state information. When these types of 
systems are modeled in SPKI/SDSI each certificate may be associated with constraints that are based on 
entity, environment or system specific information. It is possible that the collection of credentials used 
to satisfy a given authorization policy acts as a partial snapshot of the system within which the policy 
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is evaluated. The 'snapshot' provides a glimpse of the values of the system at that given moment. This 
snapshot of value is used to make authorization decision at runtime. As described by Zhang et al. in [4] 
it is possible that the access control permission on a specific resource is based on dynamic conditions like 
a user's available usage quota for a particular resource. Current approaches also have limitations when 
usage status of a shared object is employed for authorization (e.g., the usage context or constraints of 
resource object). It may also be required that these attributes which are used for authorization decisions 
are evaluated at runtime so that the last state information is used during evaluation. In addition to 
this ad-hoc and pervasive collaborations brings new challenges for authorization management. In ad- 
hoc collaboration subject authentication is not available and authorization decisions are dependent 
on contextual information [5], such as the location and time of the access request. The approaches 
known today including those provided SPKI/SDSI system lacks flexibility to support context-based 
authorizations in collaborative systems. It is possible to envision an access control system facility, 
similar to that provided by the UCON [4], in which the resource or the associated resource provider 
decides on usage constraints. 

In the era of Internet, in which unknown entities interact with each other to satisfy a request, "trust 
management" becomes the core issue [6]. In these systems a 'requester' submits a request, possibly sup- 
ported by a set of 'credentials' issued by other entities, to the resource owner. The authorization decision 
is taken based on the answer to the following question - "Do the credential provided by the requester 
prove the request complies with the policies?" . The credentials provided may be facts or can be more 
general non-local policy statement which are much more than facts. The known permission delegation 
employed in SPKI/SDSI does not allow expression of the fact that the issuer grants permissions to all 
entities that have a certain property. To simplify authorization in decentralized environments, a system 
in which access-control decisions are based on authenticated attributes of the subjects is required, and 
attribute authority is decentralized [6] . In general, the following expressiveness requirements described 
by Li et al. in [6] are required: 

1. The attributes which are evaluated for authorization decision should be decentralized. 

2. It shall be possible to delegate the attribute authority to another entity. This is required so that 
attribute verification can be managed by a single entity. 

3. Attribute-based delegation of attribute authority allows use of attribute to distribute the respon- 
sibility of attribute authority. 

4. Ability to compute conjunction of attributes is required so that an entity can use the conjunction 
of several attributes to make inferences about another attribute. 

It is required that any proposed approach based on SPKI/SDSI not only meet the requirements enu- 
merated above but also confirm to the standard as defined in RFC-2693 [2]. 



Chapter 1. Introduction 



In addition to the requirements and constraints described above an important requirement, common 
to many applications, is related to the temporal dimension of access permissions. There are many 
applications and business scenarios in which permissions should hold only for specific time intervals [7]. 
A further requirement concerns periodic authorizations. In many organizations, authorizations given to 
users must be tailored to the pattern of their activities within the organization and not just a blank set 
of authorization that are always applicable. It is essential that users must be given access authorizations 
to data only for the time periods in which they are expected to need the data to avoid misuse of resources 
and information. The development of a temporal authorization model entails several issues, including 
the definition of a formal semantics for the temporal and authorization models, the development of 
strategies for efficient access control, and the development of tools for authorization administration [7]. 

An authorization system should not only support positive authorization but should also support 
authorization which enables explicit denials. Negative authorizations allows exceptions to positive au- 
thorizations and for supporting a stricter control in the case of decentralized authorization administration 
[8]. Additional models can be envisioned when the SPKI certificate system is used not only for access 
control in the domain of information systems but also in other domains like physical facility access 
control [9, 10] and agent based transaction systems [11]. These domains require additional constraints 
that need to be included into the SPKI/SDSI system. 

Given all of the above needs the proposal for representation and evaluation should satisfy the fol- 
lowing requirements: 

• Rich Temporal Specification: The validity constraints should enable definition of temporal 
constraints which is more than just 'from time' and 'to time' specification. Facility to spec- 
ify temporal constraints like periodicity is required so that the access control policies are spe- 
cific to the resource access pattern of the user. For example, a constraint like [3 : 00PM — 7 : 
00PM on Mondays] define temporal and periodicity constraints together which states that access 
is provided only within the specified time interval [3 : 00PM — 7 : OOPAf ] and only on the specific 
day of the week (Monday). 

• Attribute Based: The keys in the SPKI/SDSI can be associated with attributes specific to the 
entity that the key is associated to. These attributes can be used for defining validity constraints 
against the certificate. For example, one of the attribute that can be checked is the role that 
the key is associated to. The authorization authority would use this to selectively grant access 
permission. 

• Usage Based: Many critical resources are assigned quota on usage to avoid misuse and manage 
allocation of usage cost. For these kind of access control systems authorization decisions are taken 
based on number of times the resource is accessed. After the expiration of the allocated quota the 
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resource is no longer accessible to the user. An example of this kind of access control can be easily 
found in the domain of physical facility access control which puts limit on number of user who 
can simultaneously access the resource. Consider the situation of a conference room which has a 
maximum occupancy of only 20 people. The usage based access control will not provide access to 
any new user trying to enter the room once the occupancy of the room has reached its limit. 

• History Based: A sequence of access to resources forms a history of access for the user. Many a 
times this history information is used as a basis of subsequent authorization. For example, it may 
be required that users access resources in a particular predefined order only. This situation is a 
common-place in the domain of physical facility access control which dictates that the user access 
a particular room only after valid entry through a sequence of doors. 

• Context Based: Context-aware computing refers to a computing paradigm in which the behavior 
of individual components is determined by the circumstances in which they find themselves to 
an extent that greatly exceeds the typical system/environment interaction pattern common to 
most modern computing [12]. The context can include state information which are global and 
information which are local to the user. In the domain of physical facility access the current room 
that the user is in and the state of the facility as a whole, like emergency situation, forms the 
context against which authorization decisions are taken. The emerging, pervasive and ubiquitous 
computing environments need security services that are non-intrusive and easily adaptable to 
changing user or environmental contexts [13]. 

• Spatial: A spatial access control model discussed here uses the spatial partition as the basis 
for defining access control constraints. Spatial model of access control is particularly useful in 
the domain of physical access control when the user physically moves from one spatial partition 
(room) to another and access resources which are spatially located. Spatial access control model 
is a very useful concept in the emerging requirement for convergence of physical and logical access 
control systems. For example, it is possible to envision a physical logical access control system in 
which access to a resource is provided only when the certificates are available in a particular set 
of physical locations. 

• Negative Authorization: A negative authorization specifies the access that must be forbidden, 
while a positive authorization specifies the access that must be granted. These kinds of autho- 
rization explicitly state the constraints that prohibits access to a specific resource. For example, 
a policy may state that all keys having a specific attribute value are debarred from accessing a 
resource. 

It can be shown that each of the constraints listed above can easily be represented as a regular expression. 
The alphabet S for the regular language represented by the regular expression depends on the type of 
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constraint modeled. A Weak monadic Second-order Logic of One Successor (WS1S), can be used in 
place of the formalism of regular expressions. This result is of interest for automata theory because 
formulas of WS1S seems to be more convenient than regular expressions for formalizing conditions on 
the behavior of automata [14]. In the following sections it is shown how WS1S can be used to represent 
constraints like those listed above. 

This work specifically attempts to provide solution for the following problems: 

• What is the most convenient representation of constraints so that constraints can be defined in a 
generic way? 

• What kind of representation of constraints allows formal analysis and evaluation? Can the known 
approaches and framework be used for efficient evaluation at runtime? 

• How can the constraints that are represented using formal yet user friendly way be associated with 
known distributed authorization infrastructure like SPKI/SDSI? 

• How can the formal models of SPKI/SDSI be modified to accommodate the flexible representa- 
tions? 

• Is the representation and its association with SPKI/SDSI system practically implementable? 

1.3 Contributions and Results 

This work is primarily focused on formally including more powerful and expressive constraints to 
SPKI/SDSI system by augmenting an established WPDS framework. The power and expressiveness 
of the framework known as AWPDS which is an augmentation over WPDS is demonstrated by the 
implementation of couple of tools. 

1.3.1 Flexible constraint definition 

A robust constraint definition framework that is based on WS1S is introduced. It is shown how most of 
the practical constraints that are defined in the literature can be specified using WS1S. The constraints 
have to be specifically modeled using WS1S based on the access control domain for which the constraint 
is being modeled. The domain of physical access control is difficult to model due to the physical 
restrictions imposed by the system and the nature of access control permissions that needs to granted 
for the physical resources that are protected. The model of secure and non-secure states in the domain 
of physical access control is different from the traditional access control system in which logical resources 
like files and directories are protected. WS1S based formulation of access control specification has been 
provided for the most commonly used constraints. In addition to this a detailed model for a physical 
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access control has been provided to demonstrate the power of using WS1S for constraint definition. A 
model for access control specification that is based on order of events is also provided. 

1.3.2 Augmentation of WPDS 

The Weighted Pushdown System (WPDS) has been augmented so that each rule can be associated 
with WS1S formula that limits the validity of the rule. The WPDS system described in [15] allows 
assignment of weights to each rule of PDS. These weights are taken from a bounded idempotent semiring. 
The ability to associate WS1S formulas to each rule of the WPDS enables richer constraint against each 
rule. The examples from [15], [16] and [17] have been used to demonstrate the application of the 
augmentation when temporal constraints are used. In these example the temporal constraints are 
represented as interval in an abstract domain but the underlying evaluation uses WS1S equivalent of 
the interval constraints. 

1.3.3 The CAP framework 

The concept of Comprehensive Authorization Problem (CAP) is formalized, as an extension over the 
Generalized Authorization Problem (GAP) defined in [15] with additional facility to specify generic 
constraints represented as regular language. It is demonstrated that various categories of constraints 
on access control defined in literature can be handled by CAP framework. The algorithm in [15] 
has been modified so that constraints can be specified using WS1S formula and manipulated using 
standard automata-theoretic operations. Only the basic algorithm of [15] is modified and the core of 
the functionality required for answering CAP problems is retained. 

1.3.4 A prototype implementation 

The algorithm and concepts presented and discussed in this thesis is implemented by building a tool 
using the MONA [18, 19, 20, 21] and WPDS library of MOPED [22, 23] tools. This tool named 
SCAT, for SPKI/SDSI Certificate Analysis Tool, allows analysis and reasoning of SPKI/SDSI certifi- 
cate set augmented with WS1S specification of temporal constraints, represented as interval over an 
abstract domain. An XML based input format is used in SCAT which allows definition of the name 
and authorization certificates along with interval based temporal constraints. The tool uses MOPED 
WPDS libraries to implement the pushdown system and the facility provided by MONA to model check 
WS1S formulas. SCAT demonstrates the practical applicability of the concepts described here with the 
limitation that generic WS1S constraints cannot be provided as input to the current version of the tool. 
A parser-complier tool has been implemented to demonstrate the feasibility of using WS1S formula in 
the complex domain of physical access control. This tool named FACT which stands for Facility Access 
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Constraint Tool provides a domain specific and easy to use language which can be syntax checked and 
converted into a WS1S formula. 



Chapter 2 

Background Information 

2.1 Simple Public Key Infrastructure and Simple Distributed 
Security Infrastructure(SPKI/SDSI) 

2.1.1 Overview 

The SPKI/SDSI is a security infrastructure whose principal goal is to facilitate the building of secure, 
scalable, distributed computing systems [24]. In SPKI/SDSI the principals are the public keys and each 
public key is a certificate authority. Each principal can issue certificates on the same basis as any other 
principal. There is no hierarchical global infrastructure. SPKI/SDSI communities can be built from the 
bottom- up, in a distributed manner, and do not require a trusted "root". 

There are two types of certificates in SPKI/SDSI - name certificates and authorization certificates. 
A name certificate defines a local name in the certificate issuer's local name space, and an authorization 
certificate grants a specific authorization from the certificate's issuer to the certificate's subject. A single 
certificate cannot both define a name and grant an authorization. Each certificate is either strictly a 
name certificate or an authorization certificate. 

In the following K, denotes the set of public keys and specific keys are denoted by K, Ka, Kb, K' , 
. . . , etc. An identifier is a word over some alphabet E. The set of identifiers is denoted by A. Identifiers 
are written in typewriter font, e.g. A and Bob. 

A term is a key follow by or more identifiers. Terms are either keys, local names, or extended 
names. 

A local name is of the form K A, where K G KL and A £ A is an identifier. For example, K Bob is a 
local name. Local names are important in SPKI/SDSI because they create a decentralized name space. 
The set of all local names is denoted by A/"l, and the local name space of K (local names of the form 
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K A) is denoted by Af L (K). 

An extended name is of the form K a, where K G K, and a is a sequence of identifiers of length 
greater than one. For example, K UW CS faculty is an extended name. Let Me be the set of extended 
names and J\Te{K) denote the set of extended names beginning with key K . The set of names in J\f is 
N L {K) U Af E (K). The set of terms T is thus /CUjV. 

2.1.2 Certificates 

SPKI/SDSI has two types of certificates, or "certs" . The first type of certificate, called name certs, 
provides definitions of local names. Authorization are specified using authorization certs or auth certs, 
for short. 

2.1.2.1 Naming 

SPKI/SDSI name certificates bind local names to public keys. Assuming each user has a single public- 
private key pair, the name-to-key binding is a multi-valued function: each name is bound to zero, one 
or more keys. A single name certificate can define a name in the issuer's local name space to be a public 
key, another name in his/her local name space, or a name in another principal's local name space. A 
name certificate that defines the local name U K A" , where K is the issuer's key, to be the subject, "S" , 
can be denoted as "K A ► S" . 

As each principal can issue name certificates, each principal has its own local name space, consisting 
of the names it defines. SPKI/SDSI, thus, has a local name space architecture, which helps to make 
the infrastructure scalable: a user does not have to ensure that the names they define are unique in a 
global name space. 

A name certificate consists of four fields: the issuer's key, an identifier, the certificate's subject, and 
a validity specification. An identifier is a single word over some standard alphabet, such as Alice, Bob, 
Friends, A, B. Following are descriptions of these certificate fields: 

• Issuer: The public key that signs the certificate. 

• Identifier: The identifier determines the local name that is being defined. The name being 
defined consists of the issuer's key and this identifier. A name certificate, thus, defines a name 
that consists of a single key followed by a single word. A name consisting of a single key followed 
by exactly one identifier is referred to as a local name. Because a name certificate can only define 
a local name, each principal can only define names within its own name space. 

• Subject: The new meaning of the local name being defined. A subject can be a public key or a 
name consisting of a single public key followed by one or more identifiers. The public key in the 
subject does not have to be the issuer's key. 



Chapter 2. Background Information 14 



• Validity Specification: The validity specification is a time period during which a certificate is 
valid, assuming the signature verifies. Beyond this period, the certificate has expired, and should 
be renewed. The validity specification takes the form (t±, £2), specifying that the certificate is 
valid from time t\ to time £2, inclusive. 

2.1.2.2 Group 

A SPKI/SDSI group is typically a set of principals. Each group has a name and a set of members. The 
name is local to some principal, who is the "owner" of the group, and the group owner is the only one 
who can change the definition of the group. A group definition may explicitly reference the members 
of the group, or reference other groups (which may even belong to someone else.) To define a group, a 
group owner issues, to each group member, a name certificate defining the local name of the group in 
the owner's name space to be that member's key or name. A group owner can also add any principal's 
group to his group by issuing name certificates binding the name of his group to the name of the group 
being added. Figure 2.1 gives an example of a SPKI/SDSI group. 



Ka friends 


~^K B 


(2.1) 


Ka friends 


^K c 


(2.2) 


Ka friends 


^K D 


(2.3) 


Ka friends — > Ke E- 


Friend 


(2.4) 


Ka friends > Kb B-Sister f 


riends 


(2.5) 



Figure 2.1: An example of a SPKI/SDSI group: Ka friends 

The ability to create groups makes security policies easier and more intuitive to define as they can be 
explicitly specified in terms of groups. As the names of the groups are at the discretion of the owners, 
groups can have meaningful, intuitive names. This makes the auditing of group definitions and ACLs 
simpler. One disadvantage of groups is that revoking the membership of a group member is non-trivial. 
If an explicit list of principals is maintained on the ACLs, the untrustworthy member's privileges can 
be easily revoked by removing his key from the ACLs. 

2.1.2.3 Authorization 

The SPKI/SDSI authorization certificate grants a specific authorization from the certificate's issuer to 
the certificate's subject. A SPKI/SDSI authorization certificate consists of five fields: the issuer's key, 
the certificate's subject, a delegation bit, a tag, and a validity specification. Following are descriptions 
of these fields: 

• Issuer: The key that signs the certificate. This issuer is the principal granting the specific 
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authorization. 

• Subject: The key or group that is receiving the grant of authorization. A subject can be a 
public key or a name consisting of a single public key followed by one or more identifiers. The 
public key in the subject does not have to be the issuer's key. 

• Tag: The tag specifies the specific authorization or authorizations being granted from the issuer 
to the subject. 

• Delegation Bit: If this bit is true, the subject of this certificate is able to grant to other 
principals any subset of the authorization that it is receiving from the issuer of this certificate. If 
this bit is false, the issuer is not delegating to the subject the authority it is granting to it. 

• Validity Specification: This is the same as that for a name cert. 

An authorization certificate in which the issuer, "if" , grants the authorization specified in the tag, "T" , 
to the subject, "S" , with the delegation bit, "p" , and a validity specification, "V" , is represented by the 
5-tuple, "(K, S, T, p, V)". The value of "p" is either true (□) or false (■). This can be denoted as "KU 
-!-> S □" if p=true otherwise U K □ -^ S ■" . 

SPKI/SDSI provides a very simple, flexible, authorization model. Authorizations can be specified 
as precisely or as generally as desired using flexible, user-defined tags. Intuitively, a tag represents a set 
of requests. 

The ability to specify authorizations in tags in certificates is a powerful notion. Conventional cer- 
tificates principally bind names to keys. However, a user's name is only one attribute of the user, and 
is rarely of security interest. An administration needs to know whether a user has been granted specific 
authorization to access the protected resource, and, if so, who granted that authorization. 

A way of considering an authorization certificate is that it transfers or propagates a specific au- 
thorization from the issuer to the subject. If the delegation bit is set in the certificate, the subject is 
allowed to continue propagating this authorization, or some subset of it, to other principals, by issuing 
authorization certificates to them. If the subject, in turn, sets the delegation bit on its certificates to 
true, the principals to whom it is propagating the authorization will also be able to issue authorization 
certificates granting new principals the authority, and so on. 

2.1.3 The Authorization Problem in SPKI/SDSI 

Let C be a set of certs and K' and R are the public keys of a client and resource owner, respectively, with 
authorization specification on the resource R is T". In the domain of authorization a problem that needs 
to be solved is the question: "Given a request r = (K', R, T"), is K' allowed to exercise authorization T" 
on i??" A certificate-chain-discovery algorithm provides not only a Yes/No answer to the authorization 
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question but also a proof if one exists. In the case of a Yes answer, certificate-chain-discovery algorithm 
identifies a chain of certificates to prove the result. Formally, certificate-chain discovery attempts to 
find, after removing useless certificates, a certificate chain c& o ■ • ■ o c\ such that 

(c fc o • ■ • o ci)(i?n) e {K'n, k'u}. 

Intuitively, (c& o • • ■ o c\) represents a path from R, the resource, to either K'O or K'U, representing 
"permission for K' to access" with and without delegation, respectively; the elimination of useless certs 
ensures that the chain represents the authorization specification T". 

Clarke et al. [25] presented an algorithm for certificate-chain discovery in SPKI/SDSI with 0(n 2 K \C\) 
time complexity, where % is the number of keys and \C\ is the sum of the lengths of the right-hand sides 
of all rules in C. However, this algorithm only solved a restricted version of certificate-chain discovery: 
a solution could only consist of a single certificate chain. Schwoon et al. [15] presented algorithms for 
full certificate-chain discovery, based on solving reachability problems in weighted pushdown systems. 
Their formalization allows a proof of authorization to consist of a set of certificate chains. The work 
presented here uses the WPDS-based algorithm for distributed certificate-chain discovery introduced by 
Schwoon et al. in [16] as it allows exploration of all valid certification chains that prove the availability 
of authorization to access a specific resource. 

2.1.4 Authorization Flow 

The SPKI/SDSI infrastructure is primarily concerned with authorizing principals to perform particular 
operations on protected resources. To provide access control on a resource, the guardian sets up an 
access control list (ACL) to protect it. Let K c be a typical user requesting to perform a particular 
operation on the resource K r . Examples of requests are a request to read a particular file, a request to 
read a file in a particular directory, a request to login to a particular account, and a request to turn on 
a particular electrical appliance or request to enter a particular room; in these examples, the 'protected 
resources' are the file, directory, account, appliance and room, respectively. For the resource owner 
(provider) to honor K c 7 s request, her request must be accompanied with a "proof of authenticity", that 
authenticates the request, and a "proof of authorization" that shows that she is authorized to perform 
the request. The "proof of authenticity" is typically a signed tag, and the "proof of authorization" is 
typically a sequence/chain of certificates. The principal that signed the tag must be the same principal 
that the chain of certificates authorizes. 

An authorization chain/flow consists of a chain of valid certificates that authorizes K c to perform 
the specific operation she is requesting to perform in the tag she signed. The proof of authorization, i.e. 
certificate chain, in K c 's request provides an authorization chain from the ACL's issuer to her public 
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key, the key that signed the request. When the K r verifies the certificate chain, it is verifying that there 
is a chain of authorization originating from it, through the ACL, through zero or more certificates, to 
K c 's key. If K r successfully verifies this authorization chain, K c is authorized to perform the requested 
operation on the protected resource. The SPKI/SDSI certificate chains which demonstrate flows of 
authorization can consist of just authorization certificates or both name certificates and authorization 
certificates. When K c is being issued her certificates, she should be given all of the certificates necessary 
to establish the necessary chain of authorization. 

To understand and analyze a set of certificates and the chain that they form for a specific client, 
resource-owner pair a formal model is required. One of the formal model of SPKI/SDSI system is 
Weighted Pushdown System (WPDS) which is described in the next section. This model is also used 
for solving the authorization and certificate chain discovery problems. 

2.2 Weighted Pushdown Systems (WPDS) 

The formalism of Weighted Pushdown System (WPDS) is described briefly and its connection to 
SPKI/SDSI system is explained. The algorithm for certificate-chain discovery given in [26] is explained. 
The concept of WPDS is an extension over Pushdown Systems (PDS). 

2.2.1 Pushdown Systems 

[16] A pushdown system is a transition system equipped with a finite set of control locations and a 
stack. The stack contains a word over some finite stack alphabet and its length is unbounded. Hence, 
a pushdown system may have infinitely many reachable states. 

Definition 9. A Pushdown System is a triple V = (P, T, A), where P and T are finite sets called 
the control locations and the stack alphabet, respectively. The elements of Conf(V) := P xP are 

called the configurations of V. A contains a finite number of rules of the form (p, 7} ^->-p (p',w) which 
define a transition relation between configurations of P as follows: 
if r = {p, 7) <^j> {p 1 , w) , then (p, 710') =^7? (p' , ww') for all ai' e P. 

(r) 

c =>p d is written to express that there exists some rule r such that c ^ d ; omit the subscript V if 
V is understood. The reflexive transitive closure of =>• is denoted by =>■*. Given a set of configurations 
C, define pre*(C) d = {d | 3c G C : d =>* c} and post*(C) d = {d \ 3c G C : c ^* c'}. Given a 
pushdown system V = {P, T, A), a regular set of configurations of V can be represented with a finite- 
state automaton, called a configuration automaton of V, whose input alphabet is Vs stack alphabet. 

Formally, a configuration automaton of V is an automaton A = (T, Q, S, P, F), where Q is a finite 
set of states and the set of locations P of V is a subset of Q, 5 C Q x T x Q, is the set of transitions] P is 
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the set of initial states; and F C Q is the set of final states. The configuration automaton's reachability 
relation, denoted by — >C Q x T* x Q , is defined as the smallest relation satisfying: 

• q — > q for every q £ Q 

• (g, 7, g') G 5, then q — > g', and 

■c w II A II T / 4-1, w 7 , 

• it g — > g and g — > g , then g — > g 

A configuration automaton accepts or recognizes a configuration (p, io) of P if p — > g for some p G P 
and q £ F. The set of configurations recognized by automaton „4 is denoted by Conf(A). 

2.2.2 Weighted Pushdown Systems (WPDS) 

Weighted pushdown systems (WPDS) were introduced in [26, 27, 15]. A pushdown system defines 
an infinite-state transition system whose states involve a stack of unbounded length. In a weighted 
pushdown system, the rules are given values from some domain of weights. The weight domains of 
interest are the bounded idempotent semirings defined in Definition 10. 

Definition 10. A bounded idempotent semiring is a quintuple (£>,©, ®, 0, 1), where D is a set, 
and 1 are elements of D, and ©(the combine operation) and ®(the extend operation) are binary 
operators on D such that 

1. (D, ©) is a commutative monoid whose neutral element is 0, and where © is idempotent. 

2. (D, <g>) is a monoid with the neutral element 1. 

3. <E> distributes over ©, i.e., for all a, b, c G D we have a® (6 © c) = (a ® b) © (a ® c) and (a © 6) ® c 

= (a® c) © (6® c). 

4. is an annihilator with respect to ®, i.e., for all a G D 1 a ® = = ® a. 

5. In the partial order C defined by: a, 6 G D, a C 6 iff a © 6 = a, there are no infinite descending 
chains. 

Definition 11. A weighted pushdown system is a triple W = (V, S, f) such that V = (P, A, T) is 
a pushdown system, S = (D, ©, ®, 0, 1) is a bounded idempotent semiring, and / : A — > D is a function 
that assigns a value from D to each rule of V '. Let it G A* be a sequence of of rules. Using /, we can 

def 

associate a value to <r, i.e., if a = [ri, . . . , r^], then we define v(a) = /(ri)®, . . . , ®/(r^). For any two 
configurations c and d of V, let path(c, c') denote the set of rule sequence [r±, . . . , r^\ that transforms c 



into c , i.e., c ^> 



^ , 
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Definition 12. Let W = (V,S,f), where V = (P, A, T) and 5 = (£>, ©, <g>, 0, 1), and let C bet a set 
of configurations. A forwards (respectively backwards) (W, C*)-dag is an edgedabeled directed acyclic 
graph (V, E) where V C Conf(T') x D and E <ZV x A xV such that 

• if a vertex (c, d) has no incoming edges, then c G C and d = 1 : 

• if ((ci, di), ri, (c, d)), . . . , ((cfc, d^, r^, (c, d)), fc > 1 are the incoming edges of (c, d), then 

— d = © i=1 (di ® f( r i)) an d c i ==^:P c f° r all 1 < i < fc (in a forwards (W, C)-dag); 

— d = ©i=i(/( r j) ® cfj) and c ==?-73 Q for all 1 < i < fc (in a backwards (W, C)-dag). 

A forwards/backwards (W, C)-dag is called a witness dag T> for (c, d) if X> is finite and (c, <i) is the only 
vertex with no outgoing edges in V. 

The extender operation ® is used to calculate the value of a path. The value of a set of paths is 
computed using the combiner operation ©. The existence of a witness dag for (c, d) can be considered 
a proof that there exists a set of paths from C to c (or vice versa) whose combined value is d. 

Definition 13. Let W = (T,S,f), where V = (P,A,L) and let C C P x T* be a regular set of 
configurations. The Generalized Pushdown Predecessor (GPP) problem is to find for each 

c e pre*(C): 

• 5(c) d = ®{v(a)\a £ path(c, d), d 6 C} 

• a backwards witness dag for (c, 5(c)). 

In [15, 26], the solutions for Generalized Pushdown Predecessor (GPP) are computed in the form 
of annotated finite automata in which the transitions are annotated with the weights. 

2.2.3 The Connection Between SPKI/SDSI and Weighted Pushdown Sys- 
tems 

The formalism of WPDS and the specification of SPKI/SDSI can be related. This relation allows use 
of the formalism for reasoning about SPKI/SDSI based systems. 

Given a finite set of certificates C such that K-c and Tq are the keys and identifiers that appear in 
C, respectively and also given the set T from which the auth specs in C are drawn, the correspondence 
between WPDS and SPKI is given as follows: 

• Sq = (T, U, n, _L, T) where U and Pi are the union and intersection of auth specs as discussed in 
[2, 28], forms a semiring with domain T. 

• associate with C the weighted pushdown system We = (Vc, Sq, /), where Vc = (K-c, ^cU{D, ■}, Ac) . 
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— the keys of C are the control locations and the identifiers form the stack alphabet; 

— the rule set Ac is defined as the set of labeled rewrite rules and / maps every rule to its 
corresponding auth spec. 

Given the above correspondence between WPDS and SPKI/SDSI a configuration (K, a) of Vc can 
reach another configuration (K' , a') if and only if C contains a chain of certificates c±, . . . , c& such that 
(c;t o . . . o ci)(Ka) = (K'a'). The label of the certificate chain is precisely v(c\, . . . , c&). Thus, solving 
the GPP problem amounts to finding a set of certificate chains to prove that a certain principal K' is 
allowed to access a resource of principal K . The solution of the problem identifies a set of certificate 
chains such that the union of their labels is maximal. 

The generalized authorization problem (GPP) in SPKI/SDSI is cast as follows: "Given a set of 
certificates C, a resource owner K r , an authorization specification T, and a client K c , are there certificate 
chain in C proving that K r grants authorization T to K C T' 

The GPP question is recast into an equivalent question in the WPDS setting as there exists a con- 
nection between SPKI/SDSI system and WPDS as demonstrated above. The equivalent GPP problem 
in the WPDS setting is: "Given C = {(IC r ,M) (/C C ,D)} and c = (/C r ,D), compute t := 5(c) and a 
backwards witness dag for (c, 5(c))". Authorization for K c is granted if and only if t D T. 

2.3 Weak monadic Second-order Logic of One Successor(WSlS) 

The Weak monadic Second-order Logic of One Successor (WS1S) is a variation of first order logic with 
the difference that it's interpretation is tied to arithmetic, somewhat weakened to keep the formalism 
decidable. In WS1S, first-order variables denote natural numbers, which can be compared and subjected 
to addition with constants. WS1S also allows second-order variables while remaining decidable; each 
such variable is interpreted as a finite set of numbers. WS1S is a logic interpreted over natural numbers, 
No = {0,1,...}. The quantification is over individual elements of No and subsets of No which follows 
natural ordering of No (unique and one successor). 

WS1S logic can help in practice to identify and to use regularity. In this logic it is possible to 
directly mention positions and subsets of positions in the string. This feature distinguishes the logic 
from regular expressions or automata. Together with quantification and Boolean connectives, an extra- 
ordinary succinct formalism arises. 

2.3.1 Syntax 

The syntax of WS1S consists of Terms, Atomic Formulas and Formulas. A term is built up from constant 
and individual variables x, y, . . . by application of successor function succ. Examples of terms are - 
0, succ(x), succ(succ(succ(67))) , succ(succ(y)) . 
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An atomic formula is of the form t = t' or t G X where t and t' are terms and A is a set variable. A 
formula is built up from atomic formulas using the Boolean connectives -i(not), V(or) with the existential 
quantifier (3). Existential quantifier (3) can be applied to both individual variables and set variables. 
Examples of formulas include: -up, <p\Zip, (3a^)</5 and 3X(ip). Remaining Boolean connectives are defined 
using -i(not) and V(or). For example - tp A i!) is defined as _, ( _i y V ~<'4>); </? => V' is defined as {-up V i[)): 
(p <-> ip is defined as (-xp V rjj) A (-i^> V 99). Universal quantifier V is defined using 3. (Vx)yj is define as 
-i((3x)-i<y9) and (yX)ip is defined as -i((3X)-«p). A few example of formulas include: 

• x ^ X is defined as -ix G A 

• A = Y is defined as (Vx)[(x G A => x G Y) A (x G y =4> x G A)] 

• Sufo(A, y) is defined as (Vx)(x G A => x G F) 

• Zero(x) is defined as (3x)[(x G A) A ->(3y)(y < x)] 

• Sing(A) is defined as (3y)[S*u6(y, X) A (Y ^ A) A ^(3Z)(Su6(Z, y) A (Z ^ y))] 

• Lt{x,y) is defined as ( VZ) [swcc(x) G Z A (VZ)(z 6Z)4 (smcc(2;) G Z)] =3~ (y G Z) 

2.3.2 Semantics 

The semantics of WS1S is such that formulas are interpreted over No. Individual variables x, y, . . . 
are interpreted as natural numbers i.e. elements of No. Function Successor corresponds to adding 
one. t = t' is true provided t and t' denote the same natural number. Set variables like A, Y, . . . are 
interpreted as subsets of No. t G A is true iff the number denoted by t belongs to the set denoted by 
A. A variable is said to occur free in a formula if it is not within the scope of a quantifier. Variables 
which do not occur free are said to be bound. For example: (3x)[(x G A) A ->(3y)(y < x)], x and y 
are bound variables and A is a free variable. </?(xi, X2, . . . , x^, X±, A2, . . . , A;) indicates all the variables 
which occur free come from {xi, X2, . . . , x^, X\, X%, . . . , A;}. To assign a truth value to the formula 
f(xi, X2, . . . , Xfc, Xi, A2, . . . , A;), map each individual variable x, to a natural number m; G No and 
each set variable Xj to a subset Mj C No. M h (p(X) denote that (p is true under the interpretation 
{xj -> m i } i6{12i j.) and {X t -> Mj} i6{1)2) . ..,;}. For example: (M,N) \= Sub(X,Y) iff M C A; 
M |= Zero(A) iff G M ; (m, n) |= Lt(x, y) iff m < n; M |= Sing(X) iff M is a singleton {m}. 

A sentence is a formula in which no variables occur free. A sentence is either true or false. Assigning 
values is not needed for a sentence. An example of a sentence is: VA[0 G A A (Vx)(x G A => succ(x) G 
X)}=> (Vx)(xG A). 

An WS1S formula (p(xi, x%, . . . , x^, X\, A2, . . . , X;) is said to be satisfiable if we can choose M\ = 
(mi,m 2 , . . . ,m k ,Mi,M 2 , ■ ■ ■ , Mi) such that Mi |= <^(Ai), where X\ = (xi,x 2 , . . . ,x fc , Ai, A 2 , . . . , A;). 
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Buchi in [14] showed that every word in L v , which is the language corresponding to the WS1S 
formula ip, has an interpretation for the free variables in p under which <p evaluates to true. Every 
interpretation which makes ip true is represented by some word in L v . ip is satisfiable iff there is some 
interpretation which makes it true iff L v is nonempty. The language L v is defined over the alphabet 
{0, l}™ 1 where m is the number of free variables in ip. Given a WS1S formula ip an automata that 
accepts L v can be constructed inductively and the set of satisfying interpretations of a subformula is 
represented by a finite-state automaton. WS1S thus acts as a notation for regular languages, just as 
regular expressions do. 



Chapter 3 



Related Work 



The work presented in this thesis is based on the prior work accomplished in the fields of model checking 
of SPKI/SDSI certificate system, certificate chain discovery in SPKI/SDSI and the distributed version of 
the same, Pushdown System and its extensions and other similar work related to SPKI/SDSI certificate 
system. In addition to this, previous results obtained in research pertaining to Decentralized Access 
Control is also cited and described here as they provide the foundation for the work in the field of using 
WS1S for constraint specification in access control domain. 

3.1 Certificate Chain Discovery in SPKI/SDSI 

A certificate-chain-discovery algorithm for SPKI/SDSI was first proposed by Clarke et al. in [25]. The 
certificate chain discovery algorithm presented takes an initial set C of certificates, an authorization that 
is desired and and public key K for which it is desired to prove that authorization exists. The proof 
consists of a chain of certificates that proves that K is authorized to access the requested resource given 
the set of certificates in C. The certificate chain discovery is the core of the work described in this thesis. 
The process of certificate chain discovery has been extended so that flexible constraints can be defined. 
An improved certificate chain discovery based on the theory of pushdown systems (PDS) was pre- 
sented by Jha and Reps [29]. The connection between SPKI/SDSI system and PDS has been demon- 
strated and certificate chain analysis problem has been solved using PDS as formalism. Jha and Reps 
also demonstrate how several useful questions about authorization can be solved by annotating the PDS 
and configuration automaton with labels from a lattice. The use of lattice restricts the authorization 
problems to those set in which constraints can be specified and reasoned using lattice. Both of the 
algorithms in [25] and [29] are centralized and assume that the proof of authorization consists of a 
single certificate chain. In general, a proof of authorization in SPKI/SDSI requires a set of certificate 
chains, each of which proves some part of the required authorization. 

23 
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The semantics of SPKI/SDSI has also been studied in [28, 30, 31]. In the proof-carrying-authorization 
(PCA) framework of Appel and Felten [32], a client uses the theorem prover Twelf [33] to construct 
a proof of authorization, which the client presents to the server. However, in this too it is assumed 
that all logical facts used by theorem prover reside at a single server/location. Li et al. in [34] present 
a distributed credential chain-discovery algorithm for the trust management system RTO. Their algo- 
rithm allows credentials to be distributed, but the proof of authorization is constructed at one site. 
The credential-chain-discovery algorithms of Li et al. fetches credentials from other sites as needed. 
Formalising the semantics of SPKI/SDSI system is of importance for evaluation of the certificate set 
and answering authorization questions pertaining to specific access requests. 

In all of the above cited work the constraint specification mechanism only allows for specific instances 
of constraint specification. The most common constraint that is specified against the rules or policies 
in the access control system is temporal constraints. 

3.2 Context Dependent Access Control 

The results on context-dependent access control is described here to understand the formalism of context- 
dependent access control as discussed in the literature and the approaches that have been taken to solve 
this problem. This understanding is relevant to the work described here to contrast with the approach 
of using WS1S formula for specifying constraints that are based on the context of the system and the 
user. 

Ruben et al. in [35] describe a context-dependent access control for web services with role-based 
approach. In the method described the permissions that are assigned to the role is dependent upon 
the identification mechanism used by the user (which defines the context of access), which implies that 
the set of permissions that are assigned to the role to which the user is associated depends upon the 
identification mechanism, unlike the challenge-response or the password based approach, used during the 
authentication phase. If a user is assigned to several role(s), it is up to the user to decide which role(s) 
he is authorized to activate. The activation depends on the way the user identifies himself. This can be 
seen as a user indirectly selecting a role to activate. This in-turn means that based on tje identification 
aspects, the user role to be activated is selected by the access control system. The definition of context 
in the approach described in this thesis is the state of the system or the user. The current state of the 
system and the user defines the constraints within which access permissions are granted to the user. 

In Junzhe et al. [36] describe the security requirements in healthcare system which require very 
dynamic and flexible policy enforcement. In the proposed security infrastructure, the policy enforce- 
ment is highly dynamic and independent from any particular application. A context constraint defined 
as a regular expression is allowed in the infrastructure which allows specification of complex context 
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related constraints to describe all kinds of security requirements. The access control scheme also consists 
of authorization policy and data access specification which together with dynamic context evaluation 
algorithm decides whether an access is authorized or not based upon the context type and its imple- 
mentation. Georgiadis and Mavridis [37] and Wang [38] both present a team-based access control model 
that is aware of contextual information associated with activities in application. Kumar et al. sum- 
marizes previous work and formally proposes context-sensitive RBAC model. The results presented in 
[36] is very relevant to the work described in this thesis as both the approaches use regular languages 
to describe the access constraints. The approach described in this work is different in the use of WS1S 
for modeling and representation of constraints and use of automata theoretic operators to extend or 
constrict the constraints. The framework proposed here also includes the constraints with SPKI/SDSI 
system so that the power of SPKI/SDSI authorization infrastructure is used. 

The access control problem for mobile agents is described in [39]. The access control function 
(ACF) takes five parameters: the credentials, operation, tuple, pattern, and the owner's profile and 
determines whether or not to allow the requested access. Formally, this function can be represented as: 
ACF :TxCxOxPxTl—> {0, 1}, where T is the universe of tuples, C is the universe of credentials, O 
is the finite set of operations, P is the universe of patterns, and II is the universe of profile. The access 
control function maps the values of the parameters to a boolean indicating the access decision. The 
context-sensitivity is in P, the universe of patterns. The pattern P used here for context-dependence 
can be related to the pattern expressed as regular language the approach presented in this thesis. The 
function ACF which maps the tuples T to access rights {0, 1} is a specific instance of mapping from 
constraints to certificates described in the results presented in this thesis. 

A framework for representing the behavior of access control policies in dynamic environment is 
presented by Daniel et al. in [40]. This paper presents formal analysis for access control policies in 
their dynamic environment. A mathematical model of policies, their environment, and the interaction 
between them is proposed. The policies of interest are captured as Datalog programs. Similar to the 
approach used in the framework proposed in this thesis, the principal source of environment information 
is defined as event which could come from user end-users, run-time systems and policy framework itself. 
Transitions in the policy's environment are triggered by various conditions. Some arise from the passage 
of time and other from user or program actions. A policy in this framework interacts with its dynamic 
environment by consulting facts in the environment and potentially constraining certain actions in the 
environment. The latter captures influence of policy decisions on an application that uses it. A policy 
and an environment model for the policy's dynamic environment combine to form a state machine over 
access tables. 

Meenakshi and Arul Ganesh et al. in [9], [10] describe a system for context based access control 
in which the policies are encoded as automata and the transitions are labeled with events which defines 
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the context of the system. The transition system that is described has event composition method that 
uses Prolog for evaluation of context. The authors describe two types of contexts that are handled by 
their framework - user context and system context. Both of these contexts for provided as events for 
the automata based access control system to react. The WS1S based specification of access control 
specification is used as the basis for definition of constraints. 

3.3 Temporality in Access Control 

A new model for representing temporal access control (TIAC) policies is introduced in [41]. In this 
model, temporal authorizations are represented by time attributes associated with both subjects and 
objects, and a "time interval access graph" . The time interval access graph is used to define constraints 
on the temporal relations between subjects and objects. Interval algebra is used to define and analyze 
the time interval access graph. The TIAC model provides formal semantics to express temporal autho- 
rization policies, in which temporal attributes of subjects and objects are used to determine authorized 
accesses. This is the first know use of interval algebra to express a temporal access control policy. 
The interval algebra provides necessary expressive power to logically describe a temporal access control 
policy, and a precise and efficient way to computationally reason about the temporal relation between 
subjects and objects and associated access constraints. In the model proposed, time is assumed to be 
a set of discrete points, T, which is isomorphic to the natural numbers and is linearly ordered with 
respect to the '<' relation. Points in T are used in representing time intervals. Time intervals are 
represented using half-open intervals denoted as r = [£—,£+) where t— < t+. Half-open intervals are 
used so that there are not semantic ambiguities about the point where two time intervals meet. Time 
intervals are associated with subjects and objects, and temporal access control policies are reasoned 
about using interval algebra. Subjects and objects each have an associated time interval attribute, 
which is used for making access control decisions. The TIAC model introduces the time interval access 
graph which is consistent instantiation of the three- vertex interval algebra network that defines access 
constraints on the temporal relations between subjects and objects, and a reference time interval (r re f). 
The access requests by a temporal subject to an object is decided based on the access mode in the 
time interval access graph. The work is relevant as it formally includes time intervals during the access 
control decision process unlike other models in which time intervals are not so closely bound with the 
access control process. The approach described in this thesis uses a temporal model which is similar 
to the time intervals described in [41]. The reasoning of time has been done using automata theoretic 
approach and the definition of the temporal interval is done using WS1S formula. 

In [7] the authors consider the problem of granting/denying authorizations with respect to time. 
They develop ways to model access control policies that vary with time and to specify policies that are 
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applicable periodically. Time is modeled symbolically as follows: 

• "Calender" is defined to be a countable set of consecutive intervals. For example, assuming hours 
as the basic calender (i.e., one unit), days can be defined as days = generate(l; hours; (24)). 
Similarly, months, years etc. are defined as various calenders. 

• "Periodic expressions" defining infinite sets of "periodic intervals" are defined. These are the usual 
time intervals, having a starting point, an ending point and a period. 

• It is argued that periodic expressions and intervals are not very convenient from the point of view 
of implementation and therefore define "gap order constraints" and "periodicity constraints" as a 
solution. These are basically relations involving <, =, integer constants and variables. For ease 
of representation and manipulation, their normal form is represented by a "temporal constraint" , 
which is a propositional logic formula over periodicity constraints and gap order constraints. 

The authors show that any symbolic periodic expression can be translated into an equivalent set of 
simple periodicity constraints. Consequently, each authorization is defined as being associated with a 
temporal constraint which takes care of the time during which the authorization exists. 
Their authorization model is defined as follows: 

• An "authorization" is defined like in Jajodia's work [42] - a 5-tuple (s,o,m,pn,g) where s, g are 
users, o is an object, m is an access mode and pn is either + or — . 

• A "periodic authorization" is given by a 4-tuple ([begin, end], P, auth) where "begin" and "end" 
signify time points, P is a periodic expression and "auth" is an authorization. 

• "Derivation rules" are inference mechanisms used to come up with new authorizations. They are 
given by ([begin, end], P, A (op) A') where "begin" and "end" are as above, A is an authorization, 
(op) is an operator which is one of WHENEVER, ASLONGAS or UPON with the usual meanings 
and A' is a boolean expression of authorizations. 

• A "temporal authorization base" is a set of periodic authorizations and derivation rules. 

Given a temporal authorization base, they illustrate how various authorizations can be derived from 
them. This generates the possibility of the set of derived authorizations derived not being unique and 
being conflicting with each other. They then present an algorithm which takes a temporal authorization 
base as input and rejects it if the set of derived authorizations is not unique. 

Finally, they show how to model access control using a temporal authorization base and discuss 
implementation issues. 
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3.4 Generalized Authorization Problem 

The work presented in this report in primarily based on the work by Schwoon et al. [15] . They formalize 
the concept of Generalized Authorization Problem (GAP) and show how this framework can be used to 
address issues such as privacy, recency, validity and trust. In the GAP framework the certificates are 
labeled with weights that are drawn from a bounded idempotent semiring. Two operators ® and © of 
the semiring are defined which is used to calculate the value of a certificate chain and a set of certificate 
chains, respectively. The language that characterize the transition sequence for the PDS V and the 
automaton A for configuration set C is formalized. An algorithm to create an annotated automaton 
that is similar to the pre* algorithm from [43] is also described. The annotation of weights against 
each certificate aids in answering several authorization related problems in which only that certificate 
chain which satisfies a specific criteria is required. A weighted SPKI/SDSI system WSS is a 3-tuple 
(C, iS, /), where C is a set of certs, S = (D, ©, ®, 0, 1) is a bounded idempotent semiring, and / : C — > D 
assigns weights to the certs in C. The function / is extended to certificate chain as: Ck o c^-\ o • • ■ o c±, 
/(cfc o c/o_i o • • ■ o ci) is defined as f{c\) ® ■ ■ ■ ® /(c;t_i) ® /(cfc). A request r is a tuple (K, R, T), where 
K is the public key of the requester, R is the public key of the resource and T is the authorization 
requested. The framework of Generalized Authorization problem is formalized in Definition 14. 

Definition 14. Given a weighted SPKI/SDSI system WSS = (C, S, f) and a request r=(K', R, T'), proof (C, r) 

denotes the set of certificate chains that prove that request r can be fulfilled. Formally, proof (C, r) is 
the set of certificate chain c& o • ■ • o c\ not containing any useless certificates such that: 

(c k o...c 1 )(Rn)e{K / n,K'u} 

The generalized authorization problem (GAP) asks the following two questions: (1) Is proof (C, r) non- 
empty? (2) If proof (C,r) is non-empty, then find the following two quantities: 

• 5 = ®{f{cc) G proof '(C, r)}, cc is a certificate chain; 

• a witness set of certificate chains to C proof (C, r) such that ® C ceuif{cc) = S. 

It is shown, using Comprehensive Authorization Problem (CAP) framework, that associating WS1S 
formula to WPDS can provide further flexibility in answering additional authorization questions. In par- 
ticular, the weighted domain in CAP consists of a regular language, represented as finite state automata, 
that is associated with each rule of WPDS (SPKI/SDSI certificate, respectively). The association of 
regular language based constraints, expressed as WS1S formula, allows definition of constraints that are 
used in the domain of access control. The expressiveness of the constraints expressed as WS1S formula is 
demonstrated using time constraints, represented as interval on an abstract domain. This representation 
allows authorization questions that can be more generic than those handled by GAP framework. 
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3.5 Logic and Access Control 

Linear time logic (LTL) is a powerful query language for asking generalized reachability questions about 
a PDS. Jha et al. in [17] provide a method of associating LTL formula with configurations of PDS. 
Given a set of atomic propositions AP and a LTL formula cf> over AP model-checking for LTL formula 
(j) on PDS V = (P, L, A) is done by associating using a labeling function Q that associates each surface 
configuration (p, 7) with with a set of atomic formula E = 2 as : (P x L) — > E. Therefore, the set 
of atomic propositions that hold at a configuration (q,jw) is given by £l({q, 7)). The model checking 
problem is: "Given a configuration c of V and an LTL formula (j), determine whether c satisfies 0" . 

The model-checking problem is solved using a Bilchi pushdown system which is a product of PDS 
and a Biichi automaton for which the acceptance condition is PDS augmented with Biichi acceptance 
condition. The Biichi pushdown system is defined as BV = {{P x Q), T, A', G), where 

• ((p,g),7>^-» ((p',q'),w) e A' if (P7) --> (p'w), q^q', <7cn«p,7». 

• (p,q) e G if q £ F. 

Given a Biichi pushdown system, the accepting-run problem is the problem of answering the question 
"Is there an accepting run starting from the configuration ((p, q),^) - i.e., a run that visits infinitely 
often the configurations with control locations in G?" . 

LTL model checking answers the following question about a PDS V = (P, T, A) and labeling function 
Q: "Does a configuration c = (p, 7) satisfy </>?. LTL model-checking can be reduced to the accepting 
run problem as follows: 

• Construct the Biichi automaton B = (E, Q, 6, go, F) corresponding to -i</>. 

• Compute BV as the product of the Biichi automaton B = (Y,,Q,5,qo, F) and the PDS V = 
(P, r, A) with respect to the labeling function £1. 

• A configuration of (p, w) violates -></> iff there is an accepting run in BV starting from the config- 
uration ((p, qo),i). 

This result is of importance as the expressiveness of this formalism is similar to the one discussed in this 
thesis. The difference is in the approach presented here and the one developed in the work presented in 
this thesis is in the ease of definition of constraints using WS1S. 

Glasgow et al. in [44] develop formal methods to reason about aspects of secrecy/security, integrity 
and accessibility. These are defined in terms of knowledge, permission and obligation as follows: 

• Secrecy: If a subject (user or process) knows a formula, then the subject must be permitted to 
know that formula. 
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• Integrity: If a subject is obligated to know a formula, then it will eventually know it. 

• Accessibility: If a subject is permitted to know a formula, then there should exist a means of 
finding it out. 

The formal notation that is developed is called "security logic" and it is built in three steps. In the 
first step a simple modal logic with a "knowledge" modality is considered. The semantics considered is 
that of "possible worlds semantics" modeled through Kripke structures. In the second step, the authors 
consider the addition of time to the logic with knowledge above as the concept of integrity is tied to 
time. The authors choose the branching interpretation of time (i.e., not linear interpretation) in order 
to conveniently talk about a world and "all" its possible future worlds. Consequently, the semantics is 
extended where the underlying models talk about a branching tree of all possible paths and temporal 
operators to quantify over these paths is added to the logic. 

In the third and final step (which leads to the full security logic) the authors extend the above logic 
by adding the deontic logic operators of "permission" and "obligation" . For the purpose of defining 
semantics, models are extended to possess "permission sets" and "obligation sets" attached to subjects 
and these sets of formulas are true whenever the corresponding subject is permitted or obligated to 
know them, respectively. 

At each of the three steps, the authors provide an axiom system and finally show that the axiom 
system for security logic is sound. Later, they illustrate how security policies can be defined in security 
logic. A point to be noted is that the security policies considered are static (i.e., they are not use- 
defined). This restriction is because permission set is attached to a subject and not to the system state. 
The above concept is illustrated by defining a multi-level secrecy policy in the logic and in the process, 
they also develop concepts for combining and composing policies. Two notions of combining policies are 
considered: 

• Compatibility: A way of combining two policies such that the resulting policy satisfies both of 
the component policies and is still secure with respect to the logic. 

• Composability: This deals with combining two different systems, each of which satisfies the 
same policy. 

Finally, the authors illustrate how security logic can be used to reason about systems by modeling 
an information flow instance of multilevel secrecy, an integrity policy, two access control instances of 
multilevel secrecy, and an access-control based policy embodying both secrecy and integrity. 
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Modeling Constraints using WS1S 



4.1 Introduction 

In the framework presented here the constraints are defined as a problem of deciding the membership in 
a regular language. For example, a rule "(r^) [£ TO ]" denotes that the rule r^ is valid only if membership 
in the regular language C m is guaranteed. Given a set of rules 7Z the restriction and extension on the 
constraint is equivalent to intersection and union on the language associated with the rule. Given a 
WS1S formula the set of satisfying interpretations of the formula can be represented by a finite state 
automata. Hence, WS1S formula has been used to define and represent constraints. It is shown how a 
variety of constraints can be modeled using WS1S. The constraints that needs to be modeled is described 
informally followed by the equivalent WS1S formula. The constraints defined in this chapter have been 
validated using MONA [19, 20], therefore the WS1S formula for each constraint is also formulated in 
the input language that MONA accepts. 

The fundamental premise that on which constraints is modeled using WS1S is based on [14] in 
which Biichi showed that every word in L v , which is the language corresponding to the WS1S formula 
ip, has an interpretation for the free variables in ip under which (p evaluates to true. Every interpretation 
which makes ip true is represented by some word in L v . ip is satisfiable iff there is some interpretation 
which makes it true iff L v is nonempty. The language L v is defined over the alphabet {0, l}™ 1 where 
m is the number of free variables in ip. Given a WS1S formula tp an automata that accepts L v can 
be constructed inductively and the set of satisfying interpretations of a subformula is represented by a 
finite-state automaton. WS1S thus acts as a notation for regular languages, just as regular expressions 
do. 
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4.2 Periodicity Temporal Constraints 

The example periodicity expression given in [7] is taken in which the temporal expression is formed 
by a periodic expression (for example, 9A.M. to 1 P.M. on Working — days, identifying the periods 
from 9 A.M. to 1 P.M. in all days excluding weekends and vacations), and a temporal interval bounding 
the scope of the periodic expression (example, [2/1997, 8/1997], restricts the preceding periods to those 
between February and August of 1997). Such expressions are converted into an interval range and 
periodicity as ([ii,*2] iP)- The time range encodes both the time and date restrictions. The WS1S 
formula is given in Figure 4.1 where isJ/alidTime is a predicate that evaluates that value of the time 
and periodicity values provided as input against the constraints specified, Imax, Imin and p specifies 
the maximum and minimum time ranges and the periodicity of the constraint, respectively. These three 
parameters together define the periodicity temporal constraint. The parameters t and d represent the 
time and periodicity values, respectively. A temporal constraints is defined such that it consists of a 



is_ValidTime(Imax, Imin, p, t, d) 

{ 

(t > min(I) At < Imax A 

((isjmonday(p) A isjnonday(d)) V 
(is_tuesday(jp) A isj,uesday(d)) V 
(isjwednesday(p) A is_wednesday(d)) V 
(is_thursday(jp) A is_thursday(d)) V 
(is_friday(p) A is_friday(d)) V 
(is_saturday(jp) A is_saturday(d)) V 
(is_sunday(p) A is Sunday (d)))) 
} 



Figure 4.1: Formula for Periodicity Temporal Constraints 

time variables x, y, . . . and an interval I which a convex subset of N. As in [45] an interval I may be 
open, half open, or closed; bounded or unbounded. An interval associated to time variable is defined to 
be of the form [a, b] , [a, oo) , (a, b] , (a, b) or (a, oo), where a < b and a, b G N. In the above definition a, b 
are called the left end-point and right end-point of / respectively. 

In this model an interval is an ordered pair of points with the first point less than the second. If 
the left end-point of an interval I is represented by 1(1) and r(I) represents right end-point relations 
between intervals I and J discussed in [46] can be defined in Table 4.1. 



Interval Relation 


Equivalent Relations on End-points 


t < s 


(t+ < s-) 


t= s 


(t- = s-)k(t+ = s+)) 


t overlaps s 


(t- < s-)k(t+ > s-)k(t+ < s+) 


t meets s 


(*+ = s-) 


t during s 


((t- > S-)&(t+ < S+))\({t- > S-)k(t+ < 8+)) 



Table 4.1: Interval Relations 
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# Days of week 




#monday 1 1 0000 1 




#tuesday 1 1 1 0001 1 




#wednesday 1 2 1 0010 1 




#thursday 1 3 1 0011 1 




#friday 1 4 1 0100 1 




#saturday 1 5 1 0101 1 




#sunday 1 6 1 0110 1 

# 

macro is_monday(varl p) = 






p notin bitO & p notin bitl & p 


notin bit2 & p notin bit3 & 


p notin bit4 & p notin bit5 & p 


notin bit6; 


macro is_tuesday(varl p) = 




p in bitO & p notin bitl & p notin bit2 & p notin bit3 & 


p notin bit4 & p notin bit5 & p 


notin bit6; 


macro is_wednesday(varl p) = 




p notin bitO & p in bitl & p notin bit2 & p notin bit3 & 


p notin bit4 & p notin bit5 & p 


notin bit6; 


macro is_thursday(varl p) = 




p in bitO & p in bitl & p notin 


bit2 & 


p notin bit3 & p notin bit4 & p 


notin bit5 & p notin bit6; 


macro is_f riday(varl p) = 




p notin bitO & p notin bitl & p 


in bit2 & p notin bit3 & 


p notin bit4 & p notin bit5 & p 


notin bit6; 


macro is_saturday(varl p) = 




p in bitO & p notin bitl & p in 


bit2 & p notin bit3 & 


p notin bit4 & p notin bit5 & p 


notin bit6; 


macro is_sunday(varl p) = 




p notin bitO & p in bitl & p in 


bit2 & p notin bit3 & 


p notin bit4 & p notin bit5 & p 


notin bit6; 


pred isValidTime(var2 Interval, 




varl periodicity, 




varl time, 




varl day) = 




(time >= min(Interval) & time <= 


= max (Interval) & 


( (is_monday (periodicity) & is_monday(day) ) 1 


(is_tuesday (periodicity) & is_tuesday(day) ) 1 


(is_wednesday(periodicity) & is. 


.Wednesday (day) ) 1 


(is_thursday (periodicity) & is_thursday(day) ) 1 


(is_f riday(periodicity) & is_fr 


Lday(day)) 1 


(is_saturday(periodicity) & is_ 


Saturday (day) ) 1 


(is_sunday (periodicity) & is_ Sunday (day) ) ) ) ; 



Figure 4.2: The MONA code for WS1S formula in Figure 4.1 
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4.3 Attribute Based Constraints 

An attribute based constraints is based on the attributes of the entities participating in access control 
system. Defining WSfS formula constraints based on attributes of entities is straight forward as it 
consists of comparison of the attribute against a value or a set of values. 

Consider the case in which an attribute named 'experience' is used in the constraints so that the 
constraint is defined such that the value of this attribute is greater than or equal to some predefined 
constant value. This case can be extended so that the constraints contains more than one attribute 
conjoined together using conjunction, disjunction and negation operators. It is also possible to include 
universal quantification and existential operators in the definition of attribute based constraints so that 
the constraints can be defined on a group. 

A hypothetical scenario that can be analyzed is a constraint on a group which restricts the group's 
access to a resource only if the group has at least one member whose 'experience' attribute has value 
greater than or equal to 25. This constraint can be represented as WS1S formula as given in Figure 
4.3. In this formula is Attribute _Exp is predicate that evaluates true if X has attribute 'Experience' has 
value greater than or equal to '25'. 



(3x : x £ X A is Attribute _Exp(x) A x >= 25) 



Figure 4.3: Formula for Attribute Based Constraints 



#Experience I 7 I 0111 I 

#The 'Experience' attribute is encoded as 
pred isAttribute_Exp(varl x) = 
x in bitO & x notin bitl & x in bit2 & 
x in bit3 & x notin bit4 & x >= 25; 

pred matchAttribute(var2 SetOf Attributes) = 

exl x: x in SetOf Attributes & isAttribute_Exp(x) ; 



Figure 4.4: The MONA code for WS1S formula in Figure 4.3 



4.4 Usage Based Constraints 



The Usage Based Constraints enforces access control restriction based on usage count of the resource. 
This usage count can be specific to a user or it is global for the resource. For example, a simple access 
control policy over a room count context specifies that "a regular user can enter room C only if the 
number of regular users in C is less than the stipulated limit." We can express the formula corresponding 
to this policy with the following subset of E: {C max ,C^ nax ,request_entry_C, allow _entryJJ} where 
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C m ax is the event that the maximum occupancy has been reached, Cf nax is the dual of the C max 
event which represents the fact that the current occupancy is less than the maximum limit. The event 
request. entry JO is generated in the system when a request for entry into room C is made by the user 
and the event allow ..entry JO is generated when the user's request for entry into room C is granted. 





Vx, Vy 




(C d max (x)A(x 


< y) A request — entry — 


C(y)A 


(-.3z((x < 


z)A(z<y))A(C max {z)) 


=> 


3w((y < w) A allow — entry — C(w 


))) 




Ww 




{all 


ow — entry — C(w) => 
3x,3y 




(C d max (x)A(x 


< y) A request — entry — 


C(y)A 


(->3z((x < z) A 


(z < y)) A (C max (z)) A (y 


<w))) 



Figure 4.5: Formula enforcing usage constraint 

Formula corresponding to the above policy, which regulates access of a regular user in room C, 
is shown gin Figure 4.5. Semantics of the policy can be understood from the words that satisfy it. 
The policy specifically rules out an occurrence of C max (represented by z) between the last seen Cf nax 
(represented by x) and request. entry JO (represented by y), if the request is to be followed by an 
allow .entry JO in a valid word. In English, the policy formula means that entry to the room is allowed 
if and only if there was a request for entry and the relevant context (C^ nax in this case) already held. 
Exact formulation of such rules may differ from one policy to another. The MONA code corresponding 
to the WS1S formula in Figure 4.5 is given in Figure 4.6. 



4.5 Spatial Constraints 

Spatial constraints are primarily defined for granting access to a facility, which consists of spaces, to 
be protected. The topology of the facility is described in terms of rooms and their neighborhood 
relationships. Consider the example facility in Figure 4.7, which comprises of five rooms, viz. A, B, 
C, D, and outside of the facility - W. The specification of the topology is elucidated in Table 4.2. The 
access to a room is gained through the door(s) associated with the room. The decision on allowing or 
denying access to a room is taken when an access request is made by the user at the door corresponding 
to the room to which access is required. 

In a normal scenario the facility administrator divides all the users into different classes or roles, 
and composes policies for each of these roles. First, this requires defining of contexts of interest using 
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pred request_into_C(varl p, varl q) 


= 






q = p + 1 & 








p in bitO & p notin bitl & 








p notin bit2 & p notin bit3; 








pred allow_into_C(varl p, varl q) = 








q = p + 1 & 








p notin bitO & p in bitl & 








p notin bit2 & p notin bit3; 








pred C_max(varl p, varl q) = 








q = p + 1 & 








p notin bitO & p notin bitl & 








p in bit2 & p notin bit3; 








pred C'_max(varl p, varl q) = 








q = p + 1 & 








p notin bitO & p notin bitl & 








p notin bit2 & p in bit3; 








pred can_enter_C(varl p, varl q) = 








alll r,s,s': C'_max(r, s) & request. 


.into. 


.C(s.s') & 


p <= r & (("exl t : (s <= t) & (t <= 


= s 


) 


& 


C_max(s', t) ) => exl s'' : allow_into. 


.C(s,s>) & 


s' <= s") => 








alll u: allow_into_C(s' , u) => 








exl x, y: C_max(u, x) & (x <= y) & 








request_into_C(x, y) & 








("exl z : (x <= z) & (z <= y) & 








C_max(y, z) & (y <= z)); 









Figure 4.6: The MONA code for WS1S formula in Figure 4.5 



which the policies are framed. Contexts are defined in terms of events. An event is an occurrence or a 
happening of significance to one or more policies. The set of events includes user actions like requests 
for services, application actions like grant/denial of services, and context events that are constructed 
with the help of application actions and/or user actions and/or other context events. For every event 
representing some context, there is a dual event that represents the absence of the same context. Hence, 
for context events, either the event or its dual is always true. Henceforth, we use the terms context 
and context event interchangeably. In our notation, the dual of a context Z is represented by Z d . To 
sum up, the set of events represents all the actions that occur in the system. Behavior of the system is 
modeled as a sequence of events, in the order in which they occur when the access control application 
is being executed. 

Consider a generic policy where access to a room, say RoomA, is allowed only in presence of relevant 
context, say Z. Z can stand for the fact that occupancy is less than 10, or that a security guard is 
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Door 2 



Door 5 



B 






P 



i 



Asset center 



D 



Door 6 






B--H &^e 



Door 4 



$ 



Door 3 




Figure 4.7: Example facility layout 



# Input topology - List of rooms 


rooms : A,B,C,D,W; 


# Input topology - Neighborhood 


neighbor A 


C.B.D.W; 


neighbor B 


A,D; 


neighbor C 


A,D; 


neighbor D 


A.B.C; 


neighbor W 


A; 



Table 4.2: Facility topology specification 



already present, or a conjunction of both. Here, we have four events, viz. request- j or- RoomA, allow- 

into-RoomA, Z, and Zjj. The generic constraint may be written as: Can enter RoomA on context Z; 

the corresponding WS1S formula being: 

Vt, 3t' : Z{t) A request - for - RoomA{t') A -i3t D : Z D (t D ) A t < t D A t D < t! =>- 3t" : allow - into - 

RoomA(t")At" = t' + lAVt" : allow- into -Roomit! 1 ) =>• 3t,t' : Z (t) Arequest- for- RoomA(t')A^3t D : 

Z D (t D ) At<t D At D <t'At' = t"-l 

which, in English means for all time instants, access is granted at this instant if and only if relevant 

context was already present, and an access request was made in the immediately preceding instant. 

Automaton for this policy is shown in 4.8. A detailed description of constraint for a sample facility is 

given in the Appendix section. 
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_allow-into-RoomA__ 




request-for-RoomA 

Z> 



all events 



Figure 4.8: FSA for access control policy 



4.6 Negative Constraints 



All the constraints described above can be formulated into their corresponding negative constraints by 
taking a negation (->) of the constraint. Thus definition of negative constraint using WS1S is trivial. 

As shown in the above sections, WS1S provides a very flexible mechanism for the definition of the 
constraints. These constraints when coupled with SPKI/SDSI validity condition provides a framework 
for the specification of PKI based infrastructure for access control in decentralized scenario. In the 
following section Weighted Pushdown System (WPDS), which is a known and well studied formal 
model, is extended so that WS1S constraints can be included into the formal framework. We call this 
framework as Augmented WPDS (AWPDS). 



Chapter 5 



Modification to WPDS 



5.1 Introduction 

In the previous chapter it was demonstrated that flexible constraints can be modeled using WS1S 
formulas. If these constraints can be associated to the rules of WPDS then a more flexible system 
can be obtained. The WPDS system allows association of weights to each rule of the PDS. These 
weights which are taken from the domain of bounded idempotent semiring brings in restriction to each 
rule. The problem that is addressed in this chapter is the association of the rules of PDS with WS1S 
based constraints. To use the formulation of WPDS it is required that the set of constraints that are 
associated to the rule be a bounded idempotent semiring. It is known that WS1S formula enables 
convenient representation but not execution. Therefore, the set of satisfying interpretations of a WS1S 
formula which denotes the constraints is represented by a finite-state automaton. The automaton for a 
formula can be calculated by a simple induction scheme, where logical connectives correspond to classic 
automata-theoretic operations such as product and subset constructions. Validity and unsatisfiability 
of the formula can be determined and satisfying examples and counter-examples can be constructed by 
analyzing the associated automaton [18]. 

5.2 Augmentation to Weighted Pushdown System (AWPDS) 

In WPDS weights are allocated to each rule of PDS. The weights allocated are values from a domain 
which is a bounded idempotent semiring. To associate generic constraint that define membership in a 
regular language the WPDS is augmented such that each rule can be associated with WS1S formula 
which is a succinct representation of a regular language of interest. Association of WS1S formula to 
each rule does not extend WPDS into a new model but only defines a new idempotent semiring domain. 
This augmentation aids in increasing the expressibility of the WPDS so that more powerful constraints 

39 
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can be associated. 

5.2.1 Augmented Weighted Pushdown System (AWPDS) 

As described earlier, the augmentation to WPDS is in terms of WS1S constraints that can be associated 
against each rule. The augmentation is as defined below. 

Definition 15. Augmented Weighted Pushdown System (AWPDS) d = An AWPDS is a tuple 
A = (W,!F, h) such that W = (V, S x Ai,g) is a weighted pushdown system, with V = (P, T, A) in 
which P is a set of control locations, T is set of stack alphabet, and A is the set of rules. T is the 
set of WS1S formula and h : A —> T is a function that assigns a value from T to each rule of V . 
S = (D, ©,<g>, 0, 1) and M. = (M, U, PI, 0, Mjy) are two idempotent semirings. M is a set m of Finite 
State Automata (FSA) such that for all / G {^(A) U f c } in which f c is the formula corresponding to 
the constraints that the AWPDS will be evaluated for and m is the FSA corresponding to all satisfying 
interpretations of / and Mjy = U x ^mx. The set M is formed from M such that M = {x\y G 2 M A x = 
U aEy a}, i.e. the elements of M are the union of subsets of the automaton in M. The function g maps 
the rules of V to the elements from D and M as g : A — > (D x M ) . 

Theorem 1. M. = (M, U, Pi, 0,M[/) is a bounded idempotent semiring. 

Proof. The set M along with operators U (union), (~l (intersection) and elements G M and M[/ G M 

satisfies the following properties: 

1. (M, U) is a commutative monoid with as its neutral element, and where U is idempotent as 
V m G M , m U = m. 

2. (M, Pi) is a monoid with the neutral element My as V m G M, mnM{7 = M{7nm = m 

3. By the property of regular languages (~l distributes over U, therefore, for all mi, 1112,1113 G M we 
have, mi (~l (1112 U 1113) = (mi Pi 1112) U (mi (~l 1113) and (mi Pi 1112) U 1113 = (mi (~l 1113) U (1112 n 1113). 

4. is an annihilator with respect to (~1, i.e., for all m G M, mn0 = = 0nm. 

5. In the partial order C defined by: for all mi, 1112 G M, mi C 1112 iff mj U1112 = mi, there are no infinite 
descending chains as My G M forms the infimum. 

Therefore, M is a bounded idempotent semiring. □ 

Theorem 2. Let Si = (D u ©, ®, 0, 1) and S 2 = {D 2 , EH, IE, _L, T) be two idempotent semirings. Their 
cartesian product S\ x S 2 = ((Di x D 2 ), +, *, {0, _L}, {1, T}) is also an idempotent semiring. 
Proof. The set (D\ x D 2 ) along with operators + and * defined on elements (pl,p2) G (D\ x D 2 ) and 
(ql,q2) G {D l x D 2 ) as (pl,p2) + (ql, q2) = (pi © gl,p2EB q2) and (pl,p2) * (ql, q2) = {pl®ql,p2Mq2), 
respectively, and elements (0, _L) G (Di x D 2 ) and (1, T) G (D\ x D 2 ) satisfies the following properties: 
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1. ({Di x 1)2),+) is a commutative monoid with (0, _L) as its neutral element, and where + is 
idempotent as V (p, g) G {D 1 x D 2 ), (p, q) + (0, _L) = (p © 0, g ffl _L) = (0, ±) + (p, g) = (p, g). 

2. ((-Di x -D2), *) is a monoid with the neutral element (1, T) as V (p, q) G {D\ x D2), (p, g) * (1, T) = 
(p * 1, q * T) = (1, T) * (p, g) = (p, g) 

3. * distributes over + (Theorem 3). 

4. (0, _L) is an annihilator with respect to *, i.e., for all (p, g) G (D\ x D2), (p, g) * (0, _L) = (0, _L) = 
(0,±)*(p,g). 

5. Define a partial order between elements (pl,p2), (gl, g2) G {D\ x D 2 ) such that (pl,p2) C (gl, g2) 
iff (pi C p2) and (gl C g2). This partial order has no infinite descending chain as (1, M) defines 
the infimum. 

Therefore, (D\ x D 2 ) is a bounded idempotent semiring. □ 

Theorem 3. Let the set (Di x D2) have operators + and * defined as (pl,p2) G (Z?i x D2) and 

(gl,g2) G (D x x D 2 ) as (pl,p2) + (gl, g2) = (pi ©gl,p2fflg2) and (pl,p2) * (gl, g2) = (pi <g>gl,p2Klg2), 

respectively. Then, * distributes over +. 

Proof. Let (pl,p2), (gl,g2), (rl,r2) G (D x x D 2 ) 

(pl,p2)*((gl,g2) + (rl,r2)) 

= (pi ® (gl © rl), p2 M (g2 ffl r2)) 

= (pi ® gl © pi ® rl), (p2 IE g2 ffl p2 IE r2) 

= ((pi ® gl), (p2 Kl g2)) + ((pi ® rl), (p2 Kl r2)) 

= ((pl,p2)*(gl,g2)) + ((pl,p2)*(rl,r2)) 

Therefore, (pl,p2) * ((gl,g2) + (rl,r2)) = ((pl,p2) * (gl,g2)) + ((pl,p2) * (rl,r2)) 

Similarly, 

((pl,p2) + (gl,g2))*(rl,r2)) 

= ((pl©gl),(p2fflg2))*(rl,r2) 

= ((pi © gl) ® rl), ((p2 ffl g2) IE r2) 

= ((pi ® rl) © (gl ® rl)), ((p2 M r2) ffl (g2 IE r2)) 

= ((pi ® rl), (p2 M r2)) + ((gl ® rl), (g2 M r2)) 

= ((pl,p2) * (rl,r2)) + ((gl,g2) * (rl,r2)) 

((pl,p2) + (gl, g2)) * (rl, r2)) = ((pl, P 2) * (rl, r2)) + ((gl, g2) * (rl, r2)) 

Hence, * distributes over +. D 

Let a G A* be a sequence of rules. Using g, it is possible to associate a value to a such that if 
a = [ri, . . . ,7-fc], then define w (<r) := ffs(n)®- ■ -®gs(rk) and w (cr) := g M (ri)D- • -ng^ (r fc ), whereas 
and g^v( are projections on elements of D and M in (D x M), respectively. For any two configurations 
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c and d of V, let path(c, d) denote the set of all rule sequences [r\, . . . , r^] that transform c into d ', i.e., 
c =*-,...,=*• c. 

Definition 16. Given a AWPDS A = (W, J 17 , /i) such that W = (V,S x M, g) is a weighted pushdown 
system, with V = (P, T, A) , and a regular set of configurations CCFxP, the Generalized Pushdown 
Reachability (GPR) problem is updated so that for each c G P xP: 

• ^ (c) := {« (<t) \<t e path (c, c') , d G C}; 

• i> (c) := U l u (°0 W ^ -P at/i ( c > c ') ^ c ' ^ c}; 

• a witness set of paths to (c) C (J c , c path (c, c') such that 0^ , > v (a) = S (c) and Uo-p^fcl u ( ff ) = 
V(c). 



5.3 Algorithm for GPR problem in AWPDS 

This section describes the algorithm that is a modification on the algorithm presented in [16]. The 
modification specifically pertains to the WS1S constraints associated to each rule. The algorithm is 
given for predecessor version of GPR given in Definition 16. 

5.3.1 Overview 

The input is an Augmented Weighted Pushdown System (AWPDS) A = (VV, T, h) along with the 
constraint f c that should be satisfied, where W = [V,S x A4,g) is a weighted pushdown system, with 
V = (P, T, A) and S = (D, ©, ®, 0, 1), S = (M, U, n, _L, T) and a regular set C of configuration. The 
output is a pre*(C) automaton from which S (c) and ip (c) and a witness set of path uj (c) can be 
computed. 

In general, there are infinitely many configurations in pre*(C) even if C itself is finite, therefore, an 
annotated finite automata is used for the purpose of computing pre* (C) . 

Definition 17. A ^-automaton is a quintuple A = (Q, T, 77, P, F) where Q D P is a finite set of states, 
r/CQxTxQ is the set of transitions, and F C Q are the final states. The initial states of A are 
the control locations P. We say that a sequence of transitions (p, 71, Pi) , . . . , (j» n -i, In, <?) £ V reads 
configuration (p, 71, . . . , 7„) if p, . . . ,p„_i, q are arbitrary states. The sequence is accepting iff q is a final 
state. If c is a configuration of A, we denote by acc^ (c) the set of all paths in A for c. The configuration 
c is accepted by A is acc^ (c) is non-empty. 

It is known from the discussions in [43] and [47] that the backward (resp. the forward) reachability 
closure of a regular set of configuration is regular. Given an automaton A that accepts the set C of 
regular configuration, it is possible to construct an automata that accepts the sets of all configurations 
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that are forward or backwards reachable from C ' . In the automaton constructed two additional labeling 
for the transitions of A are computed for the GPP. The first labeling introduced in [15], I : 77 — > D 
assigns a weight from D to each automaton transition and allows to compute 5. The second labeling 
m : r\ —> M assigns a finite state automata allows to compute final pre*(C) automaton. The WS1S 
formula is converted into an automaton representation for all the satisfying assignments of the WS1S 
formula for easier and intuitive computation of union and intersection operations. 

5.3.2 Description 

Let A = (Q, r, 77, P, F) be a "P-automaton accepting a set of configurations C. Initially, for all t £ 77, 
let l(t) := 1 and m{t) := FSA(f c ), where f c is the final constraint of the system against which the 
AWPDS is evaluated and FSA(f) returns the FSA corresponding to all satisfying assignments of the 
WS1S formula /. The following is meant when a transition t should be updated with value d G D and 
m G M: if t is not yet in 77, add t to 77 and set l(t) := l(t) © d and set m{t) := m(t) (Jm. 

For GPP, new transitions are added according the following saturation rules. These rules are an 
extension to the original set of rules given in [16]: 
If r := (73, 7) ^-> (7/, uS) is a rule, t\ . . . t\ u \ a sequence that reads (73, uS) and ends in state q, then: 

• let d be l{t\) ® ■ ■ ■ ® l(t\v\) and update (p, 7, q) with the value pri(r) ® d 

• let m be m(ti) f] ■ ■ ■ |") mit^A and update (p, 7, q) with the value 5m(?*) f] m - 

The algorithm stops when further application of the saturation rule causes no further changes in A. 

5.3.3 Algorithm 

The algorithm for computing the automaton A given the configuration set C and AWPDS A is given 
in Algorithm 1. The algorithm is similar to the certificate chain discovery algorithm in [16] except for 
the following additions: 

1. The transitions of input automaton corresponding to configuration C is updated with the final 
constraint. For all transactions t in the automaton corresponding to the initial configuration C 
set m(t) = FSA(f c ) where f c is the WS1S formula corresponding to final constraint. 

2. The transitions are updated so that both the l(t) and m(t) are updated. For each transition 
update the m. 

3. The UPDATE method is modified so that the transition's m(t) is updated with new value. 

The |J and f] operators are used to extend and restrict the constraint on the transition, respectively. 
Given two constraints the restrict operator evaluates to a constraint that is an intersection of the two 
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constraints resulting in 'tightening' of constraint. The extend operator 'relaxes' the constraint so that 
only one of them need to be valid. From a language theoretic point of view, the extend and restrict 
operators modify the language by taking union and intersection respectively. 

5.3.4 The Connection Between SPKI/SDSI and Augmented Weighted Push- 
down Systems 

The connection between SPKI/SDSI and AWPDS is similar to one described in §2.2.3 with extra con- 
nection established for the function g which maps each certificate/rule of SPKI to a WS1S formula that 
defines generic constraint for each rule along with the weights defined in [15]. 

Example 1. The connection between SPKI/SDSI is illustrated using the certificate set C shown in 
Figure 5.1. The augmented weighted pushdown system Ac = (Wc, Fc, he) Vc = {K-c, Ic U {□, ■ }, Ac), 
S = ({T}, ®, ©, _L, T), in which the <g> operators is defined so that T®T = T,T®± = _L, and © is 
defined such that T©T = T, T©_L = T . The certificates are associated with time range constraints. The 
set of all constraint is T = {[10 < x < 15], [5 < x < 9], [5 < x < 20], [10 < x < 20]}. These time range 
constraint is mapped to the rules as g = {(ri, (T, [10 < x < 15])), (r2, (T, [5 < x < 9])), (r3, (T, [10 < 
x < 15])), (r 4 , (T, [5 < x < 20])), (r 5 , (T, [10 < x < 20]))}. 

The Generalized Authorization Problem (GAP) described in [16] is updated so that the autho- 
rization problem also includes the constraints associated with each certificate. A framework called 
Comprehensive Authorization Problem (CAP) is described. It is shown that the CAP framework solves 
the GAP and other extended problems. 

5.4 Comprehensive Authorization Problems 

Given a principal K 1 a set of name and authorization certificates C, a resource R, and system constraint 
£ the Comprehensive Authorization Problem (CAP) in the context of SPKI/SDSI certificate system 
addresses the questions - Is K authorized to access resources R given £?. In the framework of CAP 
the constraint £ can be any kind of constraint that can be encoded using WS1S and hence manipulated 
using operations on a finite state automata. The AWPDS is used to answer the CAP and arrive at a 
solution. In the following it is demonstrated that several security-policy constraints like those described 
in [15] along with several others can be answered using CAP framework. 

The CAP is a further generalization of the approach used for Generalized Authorization Problem 
(GAP) which uses weighted pushdown system (WPDS). The general approach to solving CAP is as 
follows: 

• The initial automaton that accepts the configuration is constructed. 
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Algorithm 1 An algorithm for creating a extended Weighted Automaton for the GPP problem. 
Input: an Augmented Weighted Pushdown System AWPDS A = (W, T, h) such that W = 
(V, S x A4,g) is a weighted pushdown system, with V = (P, E, A) in which E is the set of stack al- 
phabet, A is the set of rules, T is a set of valid formula of WS1S and h : A — > T is a function that 
assigns a value from T to each rule of A of P\ and f c which is the WS1S formula representing the 
constraint against which the rules needs to be evaluated. An initial automaton that accepts the config- 
uration C. 

Output: an automaton A' = (Q,T,n, P, F), for pre* (C) with annotation functions I : r\ — > D and 
m : rj — > M . 



1 
2 
3 

4 

5 
(3 
7 
8 
9 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 
26 
27 
28 
29 
30 
31 
32 
33 
34 
35 
36 



procedure UPDATE(£, v, u) 
rj := ry U \t) 
newLValue := / (t) © v 
newMValue := m (t) [j u 

if newLValue ^ I (t) or newMValue ^ m (t) then 
workSet := workSet U {t} 
I (t) := newLValue 
m (t) := newMValue 
end if 
end procedure 

rj := t] ; workSet := 770 ; 
for all t G ?7o do 
l(t) := 1 

m(t) := FSA(f c ) 
end for 
for all r = (p, 7) ^-> {p 1 ', e) 6 A do 

UPDATE((p, 7 ,p'),toM,5M(r)) 
end for 
while workSet ^ do 

remove some transition t = (q, 7, q') from workSet; 
for all r = (pi , 71) ^-> (q, 7) G A do 

UPDATE(( Pl , 7l , q') , 9D (r) ® / (t) , g M (r) fl ™ (*)) 
end for 

for all r = (pi, 71) ^-> (g, 772) G A do 
for all f = (g',72,9") G 77 do 

UPDATE(( Pl , 7l , g") , g D (r) ® / (t) ® i (f ) , 9M (r) n™(t)fl™ (*')) 
end for 
end for 

for all r = (pi, 71) "^ (p 1 , 727) G A do 
if t! = (p', 72, g) G ry then 

UPDATE^ , 7l , q') , 5D (r) ® 1(f) ® Z(t), g M (r) f| m(f ) fl m(t)) 
end if 
end for 
end 'while 
return ((Q, T, n, P, F) , I, m) 
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• A set of labeled SPKI/SDSI certificates with WS1S constraints associated with each one of them is 
first translated into to an augmented weighted pushdown system (AWPDS) using the connection 
demonstrated in Section §5.3.4. 

• A shortest path problem on AWPDS is solved for finding solution to CAP. 

— A pre* automaton is formed from the initial (basic) automaton by applying saturation rule 
to add new transitions. 

— Graph shortest path algorithm is used to find the shortest path from the key, for which 
authorization is being evaluated, to the final state of the automaton, such that the transition 
is annotated with the minimum (or maximum, as applicable) of the constraint specified. 



ri := (K r ,0) -> (#„„,, facultyB) (T, [10, 15]) 


(5.1) 


r 2 := (K uw , faculty) --> (if;,, faculty) (T, [5,9]) 


(5.2) 


r 3 := (Ki„, faculty) --> {K cs , faculty) (T, [10, 15]) 


(5.3) 


r 4 := (K ls , faculty) --> (K bio , faculty) (T, [5,20]) 


(5.4) 


r 5 := (K cs , faculty) -> (K Bob , e) (T, [10,20]) 


(5.5) 



Figure 5.1: Example certificate list 



Example 2. Consider the SPKI/SDSI certificate set given in Figure 5.1 which consists of five certificates 
each associated with temporal constraints given in the form [ii,^] which represents the constraint 
that the certificate r, to which it is associated is valid only between the time range t\ and t%. The 
representation of temporal constraint is in form of interval in an abstract domain but the WS1S formula 
that is used during CAP as given below in which tl and t2 are the values from the interval defined 
against the certificate: 

var2 I where I={tl , . . . ,t2}; 

varl t; 

# 

pred Evaluate (var2 Interval, varl time) = 

(time in I) ; 

# 

Evaluated , t) ; 

Suppose that Bob wants permission t from the resource owner K r within the time units [10, 20]. 
The authorization in CAP framework finds solution to the following problem: "Is Bob authenticated by 
the key Ksob allowed access to access to resource r identified by the key K r between the time range 
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10 and 20T 7 The answer to the question is determined by solving the GPP problem on AWPDS and 
configuration C = {{K Bo b, □) , {K Bo b, ■>}■ 

The automaton that accepts the configuration C = {(Ksob, O) , (Ksob, B}} is given in Figure 5.2. 
The final automaton output by the algorithm Algorithm 1 is given in Figure 5.3. 

To provide an insight into the automaton that labels the transitions of the final automaton of 

t acuL'tu 

Algorithm 1 the automaton for the transition K uw — > Ksob is shown in Figure 5.4. Though the 
automaton looks complex the automaton is only used during the analysis phase. The MONA code that 
is used for performing union and intersection operations on the automaton is given in Figure 5.5 and 
Figure 5.6, respectively. 




□ 



(T)[10, 20] 








Figure 5.2: Initial automaton created by the algorithm 



f acult 




[11,16] 



[10,15] 



Figure 5.3: Automaton created by the algorithm 
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Figure 5.4: The automaton labeling the transition K u 



faculty 



K 



Bob 



5.4.1 Power and Expressiveness of CAP 



The main objective of augmenting WPDS and defining a CAP framework is to enable higher level of 
expressiveness for the validity constraints specified against a SPKI/SDSI certificates. 

The previous sections described with examples how AWPDS and WS1S based constraints can solve 
authorization problem in which the constraints are defined as interval on abstract domain. This section 
provides details on the use of CAP framework for addressing the access control problems discussed in 
the literature including those addressed by Schwoon et al. in [15]. 
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var2 I 1 where 


11= 


={10,. 


..,15}; 








var 2 12 where 


12= 


={10,. 


..,20}; 








var2 R; 














var 1 max ' ; 














varl min' ; 














pred Extend (var2 


p, Q, 


varl x, 


y) 


= 




R = P inter Q 


& x = max(R) & y 


= 


nin 


(R); 


Extend(Il, 12 


max' , min' ) ; 









Figure 5.5: The MONA code for Extending constraints 



var2 11 where I1={11 


...,15}; 






var2 12 where I2={12, 


...,19}; 






var 2 R; 








var 1 max ' ; 








varl min' ; 








pred Combine (var2 P, 


Q, varl x 


. y) = 




(empty(P inter Q) => 


(x = & 


y = o)) 


& 


(~empty(P inter Q) => 


(x = max 


(P union Q) & 


y = min(P union Q))), 








Combine (11, 12, max', 


min') ; 







Figure 5.6: The MONA code for Combining constraints 



5.4.1.1 Privacy-preserving certificate chains 



The concept of privacy preserving certificate chains is described by Schwoon et al. in [15] and motivated 
by the example given in Figure 5.7. 

In this example company X offers additional insurance to patients of a certain hospital H . ifjD 
represents the service offered by company X. The principals corresponding to AIDS and internal- 
medicine clinics in hospital H are denoted by Kh-AIDS and Kh-im- Alice is a patient in both the 
clinics. 

Consider the case in which Alice wants to buy the insurance from the insurance company X providing 
the special service to hospital H . The certificate set given in 5.7 results in two chains (r^) o (7-2) o (r±) and 
(r5)o(r3)o(ri) both of which is equal to KxO —> Kau C( .W. However, the certificate chain (^4)0^2)0(7-1) 
reveals that Alice probably has AIDS, which is an information that Alice may not which to reveal to 
company X. Therefore, Alice would prefer to offer the certificate chain (rs) o (ra) o (ri) to company 
X which proves that she is authorized to buy additional insurance, but reveals the least amount of 
information about her. 

Privacy can be modeled in the CAP framework using the following logic: 
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• non-overlapping intervals [S] and [I] corresponding to "sensitive" (S) and "insensitive" (I) infor- 
mation such that the max{[I]) < min([S]). 

• solve the CAP problem - "is there a certificate chain that only reveals insensitive information 
(corresponding to the interval [/]?" 

The initial automaton, final automaton and the certificate chain for the example certificate set of Figure 
5.7 is given in Figure 5.8, Figure 5.9 and Table 5.1 respectively. In this example, [I] = [1,5] and 
[S] = [6, 10]. 



n := (K x ,a) --» (ifff.patientB) [I] 

r-i := {K H , patient) <^-> (K h-AIDS, patient) [I] 

r 3 := {K H , patient) <^-> {K H -im, patient) [J] 

r 4 := {K H -AIDS, patient) ^-> {K AUce ,e) [S] 

rs ■= {K b-im, patient) <-^ {K AUce ,e) [I] 



(5.6) 

(5.7) 

(5.8) 

(5.9) 

(5.10) 



^n I associated to the certificate represents "insensitive" information. Similarly, "S" against the certificate 
denotes the fact that the certificate reveals sensitive information. 

Figure 5.7: Example certificate set for Privacy preserving chain 




D ■ 
[1,5] 








Figure 5.8: Initial automaton for privacy preserving certificate chain of 5.7 



(State, Transition) Rule Applied 



(K h , patient ■) 
{Kb —i m, patient ■) 

(K Alice, ■) 



{Kx, O) ^^ {Kb, patient ■) 

{K b , patient) ^-> {K b-im-, patient) 

{K H -i m, patient) ^ {K AHce ,e) 



Table 5.1: Example Privacy Certificate Chain 



This CAP model can solve a variant of the privacy preserving problem in which multiple privacy or 
sensitivity levels can be associated to the certificate set and the CAP question can be modified to find 
a chain which only includes certificates below a certain level of privacy and sensitivity. 
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patien 
[1,5] 




Figure 5.9: Final automaton for privacy preserving certificate chain of 5.7 

5.4.2 Maximally- valid certificate chain 

As in section §5.4.1.1 the definition of Maximally-valid certificate chain is described as follows in [15]: 
Let V(c) be the expiration value of cert c, i.e., the cert c will expire at time T current + V(c), where 
Tcurrent is the current time. The expiration value of a certificate chain c^ o Cfc_i o ■ • ■ o q is min!l =1 V(c). 
Suppose that Alice wants to login to host H . If Alice provides a certificate chain that is only valid for 
two minutes, then she will be logged off by the host after two minutes. Thus, Alice wants to find a 
certificate chain that authorizes her to login to H, but has the maximum expiration value among all 
such certificate chains. A maximally-valid certificate chain is found using the normal operation with 
the difference that the constraint for the system is kept such that the lower range is T current and the 
upper range is max(y(cj)) where 1 < i < k where k is the number of certificates in the system. Given 
the final automata formed by the algorithm Algorithm- 1, graph search is used to find the path with 
maximal validity. 



5.4.3 Most-recent certificate chain 

Let R(c) be the time (relative to the current time) when the cert c was issued or an on-line check was 
performed on cert c, i.e., T current — R{c) is the actual time of issue of the last on-line check. We call 
R(c) the recency associated with cert c. The recency of a certificate chain c^ o Ck—i o • ■ • o c\ is equal to 
max^_ 1 R(ci). Suppose that Aline wants to login to host H. For risk reduction purpose, host H might 
mandate the use of certificate chain whose recency is no more than ten minutes. In this case, Alice 
wishes to find a certificate chain that authorizes her to login to H and has the minimum recency among 
all such chains. Let c/j o Cfc_i o • ■ • o c\ be the certificate chain with minimum recency. If max\ =1 R{ci) 
is less than or equal to ten minutes, then Alice can use the certificate chain to login to H . Checking 
recency is straight forward operation in the CAP framework. The temporal range of the certificate is 
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assigned such that for all the certificates lower range is set as some constant (say 1) and higher range is 
set as R(ci). The constraint of the system is set to be such that the lower range of the constraint is the 
lower range set for all the certificates and the higher range is the recency R required. Application of 
Algorithm- 1 provides the certificate chain that satisfies the constraints of recency R, if one is available. 

5.4.4 Certificate chain with maximal trust 

Assume that each certificate c is assigned a trust level Tr(c) by the issuer of the certificate. Intuitively, 
Tr(c) denotes the confidence that the issuer of c has in the relationship expressed by the certificate c. 
The trust level of a certificate chain C& o c^-i o ■ ■ ■ o c± is §Q i=1 Tr(cj). where ® i s defined in Table 
- 5.2. Suppose that Alice wants to use server S, but has the maximal trust level among all such chains. 
If such a certificate chain has a trust level above v, Alice can use S. 





D 


© 


® 





1 


Validity 


NU{±oo} 


max 


min 


-co 


+oo 


Recency 


NU{oo} 


min 


max 


oo 





Trust 


{N, L, M, H} 


n 


U 


N 


H 



Table 5.2: Semiring for Validity, Recency and Trust 

Certificate chain with maximal trust is identified using the same method as is employed for identifying 
privacy-preserving certificate chains. The trust levels are modeled using non-overlapping intervals. The 
constraint is set so that the certificate chain is maximal with respect to the trust level. For example the 
trust levels are mapped to non-overlapping intervals in abstract domain as follows: L (low) = [5, 10], N 
(normal) = [11, 16], M (medium) = [17, 22], H (high) = [23, 28]. 



5.4.5 Order of Events 

In additional to temporal constraints which is represented as interval in abstract domain it also possible 
to check for patterns which are presented as regular language. To manage access control based on 
execution history [48] it is essential that a facility for modeling and evaluating history be available. 
The order of occurrence of events is incorporated into the definition of constraint it results in a facility 
for managing execution of history. The ordering of events define a sequence of occurrence of events 
which can be used to constraint the access permission. For example, an access control permission may 
state that the next resource requested can be granted only if the previous access request has been in a 
particular sequence. The access requests in the past is modeled as events and the order in which these 
events have happened defines the access control permission. 

Meenakshi and Arul Ganesh et al. in [49] describe a framework for decentralized physical access 
control which allows definition of order of events using WS1S formula. This framework demonstrates 
that the order and sequence of events can be described using a flexibility of WS1S logic and the same 
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can be efficiently enforced at runtime. In this framework too MONA [19] has been used as a tool for 
handling the WS1S formula. 

In the following it is described how WS1S formula can be used to describe the sequence of events 
and how the same can be associated as constraints against SPKI/SDSI certificates. The syntax and 
semantics of modeling events using WS1S is addressed followed by use of the same to define constraints. 

5.4.5.1 Syntax of Event Definition using WS1S 

The set of events is denoted by E. The atomic formulae are given by: 

• For each event e G E, we have a predicate e(x) which represents the fact that the label of the 
event represented by the variable x is e. This is required to when the ordering of events is to be 
established. 

• For first order variables x, y, the predicate x < y represents the fact that the event corresponding 
to y occurs immediately after the event corresponding to x in a computation of the system. This 
defines the natural order of the events. 

• For first order variables x, y, the predicate x < y represents the fact that the event corresponding 
to x occurs before the event corresponding to y or x refers to the same event as y in a computation 
of the system. 

• For a first order variable x and a second order variable X, the atomic formula x £ X represents 
the fact that the event corresponding to the variable x belongs the set of events corresponding to 
X. 

Formulae depicting constraints are built from the atomic formulae, using the following connectives: 

• Boolean operators representing negation and disjunction are -i and V respectively. The operators 
A (conjunction), => (implies) and = (equivalence) can be derived from -i and V. 

• The operators V(for all) and 3(there exists) is used to quantify over first and second order variables. 

To summarize, the syntax of the constraint is WS1S tuned to the context of access control and autho- 
rization. Each formula built using the above syntax defines a constraint that needs to be enforced. 

5.4.5.2 Semantics of Event Definition using WS1S 

Semantics of constraints will be defined using words over the alphabet E which defines the set of events 
of interest. Words are finite sequences of events from E. Consider a formula cf>. </> is interpreted over a 
word w as follows: An interpretation of first and second order variables is a function / that assigns a 
letter of E to each first order variable and a finite set of letters of E to each second order variable. These 
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letters occur as positions in a word when a formula (constraint) is interpreted over it. For a formula </>, 
let Vfj, denote the variables that occur free in 0, i.e. they are not in the scope of any quantifier in </> . 
Interpretation is then nothing but a function / : V^ — > E. 

The notion of when a word w satisfies a formula </>, under an interpretation I is given by w \=j </> 
and is defined inductively as follows: 

• w |=7 e(x) if and only if I(x) = e. 

• w |=7 x < y if and only if I(x) occurs before I(y) in the word w. 

• w |=7 x £ X if and only if I(x) £ I(X). 

• w |=7 ->(f> if and only if it is not the case that w \=i (j). 

• w |=7 <pi V (f>2 if and only if w \=i <j>\ or w \=j (f>2- 

• w |=7 (3x)(f> if and only if there exists an interpretation function I' that extends / by assigning an 
event to the variable x such that w \=p (p. 

• w |=7 (3X)(j) if and only if there exists an interpretation function I' that extends / by assigning a 
set of events to the variable X such that w \=i> (f>. 

A sentence is a formula without any free variables, i.e. all the variables occurring in the formula 
are bound by a quantifier. Note that sentences can be assigned semantics without any interpretation 
function. All the constraints will be sentences in WS1S. 

5.4.5.3 Example of Event Definition using WS1S 

The above description of syntax and semantics of definition of events using WS1S can be explained 

further using a simple example from the domain of physical access control. A room count event specifies 

that "user can enter room C only if the number of people in C is less than its capacity" . We can 

express the formula corresponding to this constraint with the following subset of E: {C max , C^ oa ,, 

r equest _entry J3 , allow .entry _C} in which the letter C max represents the fact that the occupancy 

of the room C has reached the maximum capacity, the event C'^ nax is the dual of the C max event 

and represents the fact that the current occupancy of the room C is below the maximum capacity, 

request. entry JO is corresponds to the event that the user has requested an entry into room C, finally 

the event allow .entry JJ represents the fact that the user is allowed entry into the room C. WS1S formula 

corresponding to the constraint is given in Figure 5.10. Semantics of the policy can be understood from 

the words that satisfy it. E.g. it specifically rules out an occurrence of a later C max happening after a 

C'max an d before a r equest. entry JO ', if it is to followed by an allow .entry JO . Thus, access will not be 

granted if C max happened to be the least event before request.entry JO , as opposed to its dual-event 
fin 

max ' 
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Vx, Vy 

(C'max( x ) ^ ( x ^ 2/) ^ request jentry JC '(y) A 

(-3z((x < z) A (z < y)) A (C mra (z)) => 

3w((y < «;) A allow _entryJJ(w))) 

^w(allow_entryJJ(w) => 

3x, 3y 

(CmW A (x < y) A request_entry _C '(y) A 

(-.3z((x < z) A (z < y)) A (C m(M (z)) A (y < id))) 



Figure 5.10: WS1S formula for the example event definition 



Chapter 6 



Prototype 



6.1 Introduction 

The concepts described in this report has been implemented in two different tools. The AWPDS is 
implemented as a tool called SCAT which allows specification of certificates along with temporal interval 
constraints. To demonstrate the ease with which complex physical access control constraints can be 
implemented a tool named FACT has been developed that takes policies from user and outputs WS1S 
based constraints. 

These tools have been designed and implemented using freely available tools like MONA and Moped. 
These tools have been used as they are robust and help reduce the overall development time. 

6.1.1 MONA 

MONA [18] is a tool that provides an efficient implementation of the decision procedure for WS1S and 
WS2S. "Efficient" in the context of the tool is defined to be that it is fast enough that it can be used for 
most practical applications. MONA translates the formula into a finite-state automaton and analyzes 
the same and provides "valid" or a counter-example. The tool requires the WS1S formula to be written 
in a specific language which is refer to as MONA whose syntax is simple and easy to use. 

A valid program file containing MONA input is provided to the tool which is compiled into an 
automaton and provides analysis results on the automaton generated. A MONA program consists of a 
number of declarations and formulas. An assignment like [P i — ► {0, 1, 2, 4}] , [Q i — ► {5}] is represented 
by 0s and Is in a string as shown in Figure 6.1 where letters are bit- vectors. Each variable is described 
by a track along the string. Here, the P-track is 111010 and the Q-track is 000001. The positions in the 
string correspond to natural numbers: a "1" in a position means that the number is in the set, a "0" 
that it is not. We can define the language associated to a given MONA program as the set of such finite 
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110 

o/ \o/ \o/ W \1 

12 3 4 5 

Figure 6.1: The input format for MONA 

strings that define satisfying interpretations. For WS1S, this language is regular, which means that it 
can be recognized by a finite-state automaton. The MONA tool is able to analyze MONA programs 
given as input to the tool and automatically translating it into the minimum automaton recognizing the 
set of satisfying interpretations. A common observation is that WS1S can be viewed as generalizations 
of quantified propositional logic, adding a single "unbounded dimension" orthogonal to the dimension 
bounded by the number of variables. 

MONA has been used in several application. It has been the foundation or successfully integrated 
into many tools. It is known that arithmetic and logic based approaches are interesting as interesting 
properties of systems can be encoded. 

6.1.2 Moped 

The Moped tool from University of Stuttgart, can check a pushdown system, from an initial configu- 
ration, against an LTL formula where the atomic predicates consists of a set of atomic symbols that 
checks the identity of the top stack symbol or the control location. In case the LTL formula is falsified 
a reduced pushdown system constructed from the original one, that also falsifies the LTL formula, is 
presented as diagnostic information. In this regard, Moped is a model checker for pushdown systems. 

6.2 SPKI/SDSI Certificate Analysis Tool (SCAT) 

The CAP framework described have been implemented using MONA tool [19, 20] and WPDS library 
provided by MOPED [23, 22]. The code base provided by MONA has been converted into a shared 
library so that the functionality provided by the MONA can be called as a method. The Weighted 
Pushdown System (WPDS) library provided by MOPED has been extended so that WS1S constraints 
can be specified against the rules of the WPDS. 

This tool named SCAT, for SPKI/SDSI Certificate Analysis tool, allows analysis and reasoning of 
SPKI/SDSI certificate set augmented with WS1S specification of temporal constraints. Only temporal 
specification can be provided as input to this tool. The input specification and the tool is such that 
it can be easily extended so that generic MONA specification can be associated with each certificate. 
The certificate set and constraints that needs evaluation is provided as input to SCAT using an XML 
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SPKI/SDSI Applications 



WPDS 
Extensions Lib 

MOPED 
WPDS Lib 



MONA 
Tool 



Figure 6.2: SCAT uses MONA and MOPED Library and implements CAP Framework 

file. The output provided by SCAT is the certificate chain that meets the system constraints if the 
constraints can be satisfied given the certificate set and its associated WSf S constraint. 



6.3 Facility Access Constraint Tool (FACT) 

WSfS logic being a mathematical language makes it cumbersome for an administrator to configure 
complex policies with. It has also been found that graphical systems are easily understood, and explicitly 
illustrate the full execution of a system. Properties can be "read off" the diagram, rather than requiring 
assertions in some symbolic language [50]. Graphical reasoning methods have particular benefits in the 
context of security protocol and access control system analysis as they allow a more intuitive reading of 
the specification, making the representation more accessible to the non-specialist. 

To get a step closer to intuitive graphical or semi-graphical methods a tool that is more attuned to 
the domain of physical facility access control has been implemented. The primary objective of this tool 
named FACT for Facility Access Constraint Tool is to demonstrate that complexity of WS1S can be 
hidden using domain specific tools. A template based approach for describing policies is implemented 
by FACT. Details regarding facility topology and events are specified by the administrator in a simple 
language, which is provided as input to the offline analyzer as shown in Figure 6.3. The template based 
configuration of policies is done such that it supports role based access control, wherein roles of users are 
defined based on the policies that are being enforced on them. Static policies as specified using ACLs 
can also be specified in which case the context of the template becomes empty. 

The example below describes how a constraint may be written as a formula in WS1S logic: 

for all [request-] or- service) 

if there exists {relevant- context) then 
there exists {grant- of- service) 
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and 

if there exists {grant- of- service) 

there exists {request- for- service) 

and 

there exists {relevant- context) 

where request- for- service, relevant- context and grant-of service are events of the application. This con- 
straints states that a service is granted if and only if there was a request made for it along with all 
the conditions required for the service to be granted (context) being true. Depending on the nature 
of policies, the event relevant-context could also be a formula of WS1S logic. It can include complex 
features to handle various parameters of dynamism like time, history, context induced by the state of 
various components of the system. 

Examples of policies for two different roles of users for our example facility are given in Table 6.2. 
Table 6.1 is an example of facility topology as used in Figure 4.7. Different processing stages within 



# Input topology - List of rooms 


rooms : A,B,C,D,W; 


# Input topology - Neighborhood 


neighbor A 


C.B.D.W; 


neighbor B 


A,D; 


neighbor C 


A,D; 


neighbor D 


A,B,C; 


neighbor W 


A; 



Table 6.1: Facility topology specification 



the offline analyzer are shown in Figure 6.3. The High Level FACDL Constraints Parser entity is 
responsible for parsing the high-level description of facility access control constraints using a language 
called Facility Access Control Description Language (FACDL). The contexts may comprise of two kinds 
of events, those events that are specific to an individual user by virtue of their own actions, and those 
events that are observed and constructed by the system for use in one or more user classes. Individual 
user actions comprise the history of the user. The high level constraints parser parses the specifications 
of such events declarations and usages, and uses them to construct (predefined) regular expressions 
with respect to the kind of history in question. For example, the constraint for a regular user for entry 
to room C, in Table 6.2, requires history event hi. ISSUE ASSET x IN d implies that user must 
enter room D, and issue an asset X. Therefore, in order to enter room C, the user history must contain 
the sequence request_entry_D, allow _entry_D, request_asset_X, issue_asset_X. h2 is therefore written as 
a regular expression representing this sequence. Also, policy templates starting with CAN_ENTER, 
depending upon the kind of context that they use, are substituted by corresponding WS1S formulae. 
For example, the policy of a regular user for room C is translated into the WS1S formula of Figure 4.5. 



Chapter 6. Prototype 



60 



# Define system context 


# Role based policy for 


Regular users 


EVENT C max : IS count event 


policyclass 


regular: 




USES user-entry IN C 


CAN_ENTER 


W on Ja 




USES user-exit FROM C 
PARAM_val GEO. 10 
PARAM_user-class EQ regular 


CAN_ENTER 
CAN_ENTER 
CAN_ENTER 


A 

B ON.CONTEXT 

C ON.CONTEXT 




B max AND hi 


^max 


PARAM_room EQ C 


CAN_ENTER 


D ON.CONTEXT 


hi 


EVENT escort-Timer : IS timer event 


policyclass 


visitor: 




USES user-entry IN SELF 


CAN_ENTER 


W 




USES user-exit FROM SELF 


CAN_ENTER 


A 0N.C0NTEXT 


Regular^escort 


PARAM_val EQ 10 


CAN_ENTER 


B 0N.C0NTEXT 


Regular-escort 


PARAM_user-class EQ regular 


CAN_ENTER 


C 0N.C0NTEXT 


Regular-escort 




# Default 


deny for room D 


EVENT Regular-escort : IS timed event 








USES e.scortJTimer 








PARAM_escort-class EQ regular 








PARAM_room EQ SELF 








# User history based context 








HISTORY hi: ANTI-PASSBACK IN D 








HISTORY hi: ISSUE ASSET X IN D 









Table 6.2: Context and policy specifications 



Maintenance of system context, on the other hand, is the responsibility of the system as a whole. 
Assume that B max is defined similar to C max . It is an example of system context that is true if the count 
of regular users in room B is greater than or equal to 10. For a regular user to enter room B, B max must 



be false, i.e. B max must be true. Final grant/deny decision, however, is taken after evaluating both 
the system context and the history h2 of the user. The offline analyzer, therefore, must also generate 
configuration information for the context modeling machinery that dictates how contexts are handled. 
The USES keyword in Table 6.2 describes dependency of a context event on other events. Here it is 
assumed that application events user- entry (to a room) and user- exit (from a room) are events that are 
generated every time a user enters or leaves a room respectively. 

The SELF keyword is a syntactic sugar. The Regular-escort context is defined once, but is used in 
connection with various rooms. We could have defined this context with respect to individual rooms 
in which we foresee its use. Alternatively, we use the keyword SELF for the room parameter, and 
instantiate this context for rooms A, B, and C at compile-time as and when it is encountered in any 
user's policy. 

The FACDL is a proprietary language that has been defined with focus on the requirements for 
physical access control. The High Level FACDL Constraints parser is a compiler that checks for the 
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Set of FACDL 
based Constraints 























High Level FACDL 

Constraints Parser 










WS1S based 

Constraints 






WS1S 

Constraint 
Analyzer 





































Figure 6.3: Organization of FACT 



syntax and the semantics of the constraint defined using FACDL. The parser also generates WS1S based 
constraints for valid FACDL input. The WS1S constraints analyzer uses MONA to analyze the WS1S 
constraints generated. 



Chapter 7 

Summary, Conclusions and Future 
Work 



The WPDS formalism and SPKI/SDSI system is known to have direct correlation between them. Given 
a SPKI/SDSI certificate set it is possible to define an equivalent WPDS in which the keys of certificate 
set becomes the control locations and the identifiers form the stack alphabet. The set of labeled rewrite 
rule becomes the transitions of WPDS. This equivalence allows the user of WPDS reachability algorithm 
to answer the SPKI/SDSI authorization questions. WPDS allows association of weights to each rule 
which is used to constrain the search when solving Generalized Predecessor Problem. A more generalized 
constraint can be defined by associating validity of a rule to the membership to a regular language. In 
the framework described here WS1S is used as a representation for the regular language of interest as 
the set of all valid interpretations of a WS1S formula can be represented by a finite state automata. This 
framework coupled with WPDS gives rise to an Augmented WPDS (AWPDS) which allows evaluation 
of SPKI/SDSI certificates which are associated to complex constraints and is powerful enough to be 
able to specify wide variety of constraints which include temporal, spatial and other constraints defined 
in the literature. The framework called Comprehensive Authorization Problem (CAP) based on WPDS 
library and MONA tools. This tool named SCAT, for SPKI/SDSI Certificate Analysis tool, allows 
analysis and reasoning of SPKI/SDSI certificate set augmented with WS1S specification of temporal 
constraints. In addition to SCAT another tool/parser-compiler has been implemented to demonstrate 
that WS1S can be used even for the definition of constraints from the physical access control domain. 
This tool named FACT for Facility Access Constraint Tool provides a domain specific language for the 
definition of access control constraints typically used for physical access control. 

In addition to the work presented here there many improvements and extensions that are possible 
which are listed below; 
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• SCAT can be extended in the following ways: 

— Making constraints specification more generic so that flexible constraints can be specified 
against certificates. This requires changing the input format so that comprehensive WS1S 
formula, expressed in MONA language, can be associated against each certificate. 

— Confirming to standards like XACML [51], which is a markup language that has been 
approved by OASIS. XACML promises to standardize policy management and access decision. 
It defines a general policy language used to protect resources as well as an access decision 
language. Conformance to XACML will provide interoperability to existing systems and 
provide an opportunity for deployment in real world scenario. 

— Integration to available SPKI/SDSI implementations. Many implementation of SPKI/SDSI 
2.0 standards are available (e.g. Pisces, JSDSI, SPKI/SDSI certificate infrastructure ). Ex- 
tension of these libraries and systems will demonstrate the power of CAP framework proposed. 

• Additional security framework proposed in the literature can be modeled using the CAP frame- 
work. This requires further investigation. This thesis has only taken few example from the liter- 
ature. To demonstrate both the power and limitations of the approach discussed the framework 
should be used on other examples and access control scenarios. 

• Optimization of the tool by tighter integration with MONA source code is required. Such an 
optimization will make the tool usable in real- world scenario. 

• A distributed version of the CAP framework need to be developed so that the case of distributed 
certificate chain discovery, as handled in [16], can be demonstrated. 



Appendix A 

Example Space Constraints Using 
WS1S 

A.l Overview 

The domain of physical access control deals with policies that deny or grant access to specific physical 
spaces in a facility. The physical space of interest in a facility which is a room. The access to a room 
is granted through a door(s). To gain entry into a room the user makes a request for entry into the 
room. This request results in either a 'allow' or 'deny' action based on the policies defined for the user. 
The policies defined for the user can be static- which means the access decision are taken only based on 
parameter(s) that do not mutate or change dynamically, or dynamic - which means that policy is based 
on parameters or attributes that varies with time or context in which the request is made. 

In what follows constraints are defined using MONA, which is an language for specifying WS1S 
formula, for a simple facility that has four rooms - Rl, R2, R3 and R4. A set of events are defined to 
illustrate how events can be combined together for specifying constraints. The entire code that specifies 
the constraints is organized into 'decl.mona', 'atomic. mona', 'lib.mona' and 'example. mona' which are 
described in separate sections. 

A. 1.1 Declaration 

The MONA file 'decl.mona' contains the set of common declarations that are used in other files. 

# The statement below states that the elements of $ 
is such that it contains successor elements .var2 $ 
where ~exl p where true: p notin $ & p+1 in $; 
allpos $; 

# The declarations restrict all variables to $. 
def aultwherel (p) = alll r: r < p => r in $; 
defaultwhere2(P) = alll p: p in P => alll r: 

r < p => r in $; 

# declare a string of 8-bit vectors 
var2 bitO where bitO sub 

bitl where bitl sub 

bit2 where bit2 sub 

bit3 where bit3 sub 

bit4 where bit4 sub 

bit5 where bit5 sub 

64 



Appendix A. Example Space Constraints Using WS1S 65 



bit6 where bit6 sub $, 
bit7 where bit7 sub $; 

A. 1.2 Library Code 

The common set of predicates that are used elsewhere is grouped together into the file 'lib.mona'. The 
file contains predicates that evaluate if an input sequence defines presence is a room, or if a specific event 
has occurred as seen from the input sequence given. A predicate defined is related to anti-passback. In 
the context of physical facility access control anti-passback specifies the constraints that a user should 
be denied entry into a room if valid exit from the room is not seen. This constraint avoid misuse of 
authorization provided to a user. 

# Lib predicates 

pred in_R2(varl p, varl q) = 

exl r , s, s' : 

request_into_R2(r , s) & p <= r 

& 

allow_into_R2(s,s' ) & s' <= q 

& 

~exl t,t': allow_into_R3(t,t') ft s < t & t' <=q 

I 

allow_into_Rl(t,t') ft s < t ft t' <=q 



pred antipassback_violation_R2(varl p, varl q) = 

P < q 

& 

exl r , s, s' ,u,u' : 

request_into_R2(r , s) & p <= r 

& 

allow_into_R2(s,s' ) & s' <= q 

& 

( 

"exl t,t': allow_into_R3(t,t') ft s < t ft t' <=q 

I 

allow_into_Rl(t,t') ft s < t ft t' <=q 

) 

& 

request_into_R2(u,u' ) & s < u & u' <= q 



pred is_last_Za(varl p, varl q) = 

P < q 

& 

exl t,t' : 

is_Za(t,t') ft p <= t ft t' <= q 

& 

( 

~exl v,v' : is_Za'(v,v') & t < v & v' <= q 

); 

pred is_last_Za' (varl p, varl q) = 
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p < q 
& 

exl t,t' : 

is_Za'(t,t') & p <= t & t' <= q 



( 

~exl v,v' : is_Za(v,v') & t < v & v' <= q 

); 

pred is_last_Zb(varl p, varl q) = 
p < q 



exl t,t' : 

is_Zb(t,t') & p <= t & t' <= q 



( 

"exl v,v': is_Zb'(v,v') & t < v & v' <= q 

); 

pred is_last_Zb' (varl p, varl q) = 
p < q 



exl t,t' : 

is_Zb'(t,t') ft p <= t ft t' <= q 

& 

( 

~exl v,v' : is_Zb(v,v') & t < v & v' <= q 

); 



A. 1.3 Atomic Formulae 

A set of atomic predicates that are used during the formulation of higher level of constraints is defined 
in 'atomic. mona' file. A binary code is allocated to each user-generated and system-generated events so 
that the occurrence of the events is a string of input can be identified. 

# String identifiers of all events. 

# + + 



#Rooms: Rl, R2, R3, R4 
#events_on_rooms : R, A, D 
#other events: Za, Zb 
# 

# Generated events 

# 

#R_R1 

#A_R1 

#D_R1 

#R_R2 

#A_R2 

#D_R2 

#R R3 



1 


0000 I 


1 1 


0001 I 


1 2 


0010 I 


1 3 


0011 I 


1 4 


0100 I 


1 5 


0101 I 


1 6 


0110 I 
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#A_R3 

#D_R3 

#R_R4 

#A_R4 

#D_R4 

#Za I 12 I 

#Za> I 13 I 

#Zb I 14 I 



7 I 0111 I 

8 I 1000 I 

9 I 1001 I 

10 I 1010 

11 I 1011 

1100 I 

1101 I 
1110 I 



#Zb' I 15 I 1111 



# +- 



p notin bitl 
p notin bit3; 



# Room Rl 

pred request_into_Rl (varl p, varl q) 

q = p + 1 & 

p notin bitO 

p notin bit2 c6 p iiuuxii uilo, 

pred allow_into_Rl (varl p, varl q) = 

q = p + 1 & 

p in bitO & p notin bitl & 

p notin bit2 & p notin bit3; 

pred deny_into_Rl (varl p, varl q) = 

q = p + 1 & 

p notin bitO & p in bitl & 

p notin bit2 & p notin bit3; 

# Room R2 

pred request_into_R2(varl p, varl q) 

q = p + 1 & 

p in bitO & p in bitl & 

p notin bit2 & p notin bit3; 

pred allow_into_R2(varl p, varl q) = 

q = p + 1 & 

p notin bitO & p notin bitl & 

p in bit2 & p notin bit3; 

pred deny_into_R2(varl p, varl q) = 

q = p + 1 & 

p in bitO & p notin bitl & 

p in bit2 & p notin bit3; 

# Room R3 



pred request_into_R3(varl p, varl q) 

q = p + 1 & 

p notin bitO & p in bitl & 

p in bit2 & p notin bit3; 

pred allow_into_R3(varl p, varl q) = 

q = p + 1 & 

p in bitO & p in bitl & 

p in bit2 & p notin bit3; 

pred deny_into_R3(varl p, varl q) = 
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q = p + 1 & 

p notin bitO & p notin bitl 

p notin bit2 & p in bit3; 



# Za. 

pred is_Za(varl p, varl q) = 
q = p + 1 & 

p notin bitO & p notin bitl & 
p in bit2 & p in bit3; 

# Za' . 

pred is_Za' (varl p, varl q) = 
q = p + 1 & 

p in bitO & p notin bitl & 
p in bit2 & p in bit3; 

# Zb. 

pred is_Zb(varl p, varl q) = 
q = p + 1 & 

p notin bitO & p in bitl & 
p in bit2 & p in bit3; 

# Zb' . 

pred is_Zb'(varl p, varl q) = 

q = p + 1 & 

p in bitO & p in bitl & 

p in bit2 & p in bit3; 

A. 1.4 Example Policy Set 

The actual set of constraints that are associated to a group of user is given here. The set of users are 
grouped into classes named Ul, U2, U3, U4 and Uadm. The Uadm class is the administrative user 
who has special permissions. The other classes of users are arbitrary and may be used defined. In the 
constraints defined below the dual of an event, say Z, is presented with a apostrophe (') as in Z' . 

# Template predicates 

include "decl .mona" ; 
include " atomic. mona" ; 
include "lib. mona"; 

# Policyclass Ul 



pred can_enter_Rl_on_Za' (varl p, varl q) = 

alll r,s: 

request_into_Rl (r , s) & p <= r 

& 

is_last_Za' (p,r) 

=> 

exl s': allow_into_Rl(s,s') & s' <= q; 

pred cannot_enter_Rl_on_Za(varl p, varl q) 
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alll r,s: 

request_into_Rl (r , s) & p <= r 

& 

is_last_Za(p,r) 

=> 

exl s': deny_into_Rl (s, s' ) & s' <= q; 

pred can_enter_R3(varl p, varl q) = 

alll r,s: request_into_R3(r , s) & p <= r => exl s' 

: allow_into_R3(s, s' ) & s' <= q; 



pred policyclass_Ul (varl p, varl q)= 

can_enter_Rl_on_Za' (p,q) 

& 

cannot_enter_Rl_on_Za(p, q) 

& 

can_enter_R3 (p , q) 



# Policyclass U2 

pred can_enter_R2_on_Zb_and_Za' (varl p, varl q) = 

alll r,s: 

request_into_R2(r , s) & p < r 

& 

( 

is_last_Zb(p,r) 

& 

is_last_Za' (p,r) 

) 

=> 

exl s': allow_into_R2(s,s') & s' <= q; 

pred cannot_enter_R2_on_Zb'_or_Za(varl p, varl q) 

alll r,s: 

request_into_R2(r , s) & p < r 

& 

( 

is_last_Zb' (p,r) 

I 

is_last_Za(p,r) 

) 

=> 

exl s': deny_into_R2(s, s' ) & s' <= q; 

pred can_enter_R3_on_Zb_and_Za' (varl p, varl q) = 

alll r,s: 

request_into_R3(r , s) & p < r 

& 

( 
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is_last_Zb(p,r) 

& 

is_last_Za' (p,r) 

) 

=> 

exl s': allow_into_R3(s, s' ) & s' <= q; 

pred cannot_enter_R3_on_Zb'_or_Za(varl p, varl q) 

alll r,s: 

request_into_R3(r , s) & p < r 

& 

( 

is_last_Zb' (p,r) 

I 

is_last_Za(p,r) 

) 

=> 

exl s': deny_into_R3(s, s' ) & s' <= q; 

# caimot_enter_Rl_on_Za 

# can_enter_Rl_on Za' 

pred policyclass_U2(varl p, varl q) = 

can_enter_R2_on_Zb_and_Za' (p, q) 

& 

cannot_enter_R2_on_Zb ' _or_Za (p , q) 

& 

can_enter_R3_on_Zb_and_Za' (p, q) 

& 

cannot_enter_R3_on_Zb ' _or_Za (p , q) 

& 

cannot_enter_Rl_on_Za(p,q) 

& 

can_enter_Rl_on_Za' (p,q) 



# Policyclass U3 

pred can_enter_Rl (varl p, varl q) = 

alll r,s: request_into_Rl (r , s) & p <= r => exl s' 

: allow_into_Rl (s, s' ) & s' <= q; 

pred can_enter_R2(varl p, varl q) = 

alll r,s: request_into_R2(r , s) & p <= r => exl s' 

: allow_into_R2(s, s' ) & s' <= q; 

# can_enter_R3 

pred policyclass_U3(varl p, varl q) = 

can_enter_Rl (p, q) 

& 

can_enter_R2(p, q) 
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can_enter_R3 (p , q) 
> 

# Policyclass U4 



pred can_enter_R2_on_Zb_and_not_Za(varl p, varl q) = 

alll r,s: 

request_into_R2(r , s) & p < r 

& 

( 

is_last_Zb(p,r) 

& 

~is_last_Za(p,r) 

) 

=> 

exl s': allow_into_R2(s,s') & s' <= q; 

pred cannot_enter_R2_on_Zb'_or_not_Za' (varl p, varl q) = 

alll r,s: 

request_into_R2(r , s) & p < r 

& 

( 

is_last_Zb' (p,r) 

I 

~is_last_Za' (p,r) 

) 

=> 

exl s': deny_into_R2(s, s' ) & s' <= q; 

pred cannot_enter_R2_on_antipassback_violation_R2(varl p, 

varl q) = 

alll r,s,t,u: 

request_into_R2(r , s) & p <= r 

& 

p <= t & t <= r 

& 

antipassback_violation_R2 (t , s) 

=> 

exl s': deny_into_R2(s, s' ) & s' <= q; 



pred can_enter_R2_on_not_aiitipassback_violatioii_R2(varl p, 

varl q) = 

alll r,s,t: 

request_into_R2(r , s) & p <= r 

& 

p <= t & t <= r 

& 

~antipassback_violation_R2(t , s) 

=> 

exl s': allow_into_R2(s,s') & s' <= q; 
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pred can_enter_R3_on_Zb_and_not_Za(varl p, varl q) = 

alll r,s: 

request_into_R3(r , s) & p < r 

& 

( 

is_last_Zb(p,r) 

& 

~is_last_Za(p,r) 

) 

=> 

exl s': allow_into_R3(s, s' ) & s' <= q; 

pred cannot_enter_R3_on_Zb'_or_not_Za' (varl p, 

varl q) = 

alll r,s: 

request_into_R3(r , s) & p < r 

& 

( 

is_last_Zb' (p,r) 

I 

~is_last_Za' (p,r) 

) 

=> 

exl s': deny_into_R3(s, s' ) & s' <= q; 

# caimot_enter_Rl_on_Za 

# can_enter_Rl_on_Za' 

pred policyclass_U4(varl p, varl q) = 

can_enter_R2_on_Zb_and_not_Za (p , q) 

& 

cannot_enter_R2_on_Zb'_or_not_Za' (p, q) 

& 

cannot_enter_R2_on_antipassback_violation_R2(p, q) 

& 

can_enter_R2_on_not_antipassback_violatioii_R2(p, q) 

& 

can_enter_R3_on_Zb_and_not_Za (p , q) 

& 

cannot_enter_R3_on_Zb'_or_not_Za' (p, q) 

& 

cannot_enter_Rl_on_Za(p,q) 

& 

can_enter_Rl_on_Za' (p,q) 

# Policyclass Uadm 

# Note : This is an expand - not a default restrict 

# can_enter_Rl 

# can_enter_R2 

# can enter R3 
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pred policyclass_Uadm(varl p, varl q) 
can_enter_Rl (p, q) 



can_enter_R2(p, q) 

& 

can_enter_R3(p, q) 



# + + 

# Random other policies. . . . 

pred cannot_enter_Rl (varl p, varl q) = 

alll r,s: request_into_Rl (r , s) & p <= r => exl s' 

: deny_into_Rl (s, s' ) & s' <= q; 

pred cannot_enter_R2(varl p, varl q) = 

alll r,s: request_into_R2(r , s) & p <= r => exl s' 

: deny_into_R2(s, s' ) & s' <= q; 

pred cannot_enter_R3(varl p, varl q) = 

alll r,s: request_into_R3(r , s) & p <= r => exl s' 

: deny_into_R3(s, s' ) & s' <= q; 

pred can_enter_R2_on_Za(varl p, varl q) = 

alll r,s: 

request_into_R2(r , s) & p <= r 

& 

is_last_Za(p,r) 

=> 

exl s': allow_into_R2(s,s') & s' <= q; 

pred cannot_enter_R2_on_Za' (varl p, varl q) = 

alll r,s: 

request_into_R2(r , s) & p <= r 

& 

is_last_Za' (p,r) 

=> 

exl s': deny_into_R2(s, s' ) & s' <= q; 

pred can_enter_R2_on_Za_and_Zb(varl p, varl q) = 

alll r,s: 

request_into_R2(r , s) & p < r 

& 

( 

is_last_Za(p,r) 

& 

is_last_Zb(p,r) 

) 

=> 

exl s': allow_into_R2(s,s') & s' <= q; 

pred can_enter_R2_on_Za_or_Zb(varl p, varl q) = 
alll r.s: 
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request_into_R2(r , s) & p < r 

& 

( 

is_last_Za(p,r) 

I 

is_last_Zb(p,r) 

) 

=> 

exl s': allow_into_R2(s, s' ) & s' <= q; 

# + 



can_enter_R2(0,max($)+l) ; 
cannot_enter_R2(0,max($)+l) ; 
can_enter_R2(0,max($)+l) & 
can_enter_R2_on_Za(0,max($)+l) & 
cannot_enter_R2_on_Za' (0,max($)+l) ; 
in_R2(0,max($)+l) ; 

antipassback_violation_R2(0,max($)+l) ; 

cannot_enter_R2_on_antipassback_violation_R2(0,max($)+l) ; 
can_enter_R2_on_not_antipassback_violatioii_R2(0,max($)+l) ; 
can_enter_R2_on_Za_and_Zb(0,max($)+l) ; 
can_enter_R2_on_Za_or_Zb (0 , max ($ ) +1 ) ; 



policyclass_Ul(0,max($)+l)& 
policyclass_U2(0,max($)+l)& 
policyclass_U3(0,max($)+l)& 
policyclass_U4(0,max($)+l)& 
policyclass_Uadm(0,max($)+l) ) ; 

can_enter_Rl(0,max($)+l) I 
can_enter_R2(0,max($)+l) ; 
can_enter_R3(0,max($)+l) ; 
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